Revert "Deprecate Python 2 installations"#28411
Conversation
adamjstewart
force-pushed
the
revert-28003-packages/python2
branch
from
45d21dc to
08ef74d
Compare
For future reference, RHEL8 platform python is 3.6, so IMO that is the oldest 3.x python we really need to care about. I don't see 3.5 in the wild very much (at all). |
|
@scheibelp @varioustoxins reminder to review this PR and make sure that Python 2 support works as expected. |
|
@scheibelp will you be able to look at this one soon? |
| - default_specs: | ||
| - lz4 # MakefilePackage | ||
| - mpich~fortran # AutotoolsPackage | ||
| - tut # WafPackage |
There was a problem hiding this comment.
Why is this needed?
Every other change looks fine to me. I'd ask in general though:
- Why deprecate things that depend on python@2 (i.e. why not let the deprecation of Python 2 address that when it comes to it)?
- Do we need different deprecation "modes" i.e. something finer-grained than boolean:
- Installing the package is allowed but warn
- Installing the package is not allowed but existing installs are ok
- Existing installs are not allowed
There was a problem hiding this comment.
Why is this needed?
@tgamblin asked me to revert #28360, the WafPackage test was removed because tut became deprecated, but now that tut is no longer deprecated we should test again.
Why deprecate things that depend on python@2 (i.e. why not let the deprecation of Python 2 address that when it comes to it)?
I chose to deprecate other packages in addition to EOL Python in #28003 so that we could get an idea of how many packages would be affected, and so that we could notify the maintainers of those packages. Now that EOL Python is no longer deprecated, we are also removing those package deprecations.
Do we need different deprecation "modes" i.e. something finer-grained than boolean
@haampie suggested the same thing on Slack today. Regardless of whether or not we should do this, this doesn't affect Python packages. @varioustoxins (and presumably others) wants to be able to install Python 2-only packages using Spack. I'm assuming this also includes installing on systems without a Python 2 external. We need to remove deprecations from all packages regardless.
There was a problem hiding this comment.
Do we need different deprecation "modes" i.e. something finer-grained than boolean
For reference, we discussed that issue when we hooked the deprecated keyword to the concretizer #23491 (review) (in particular see this comment from @sethrj #23491 (comment) which gives a lot of good reasons to keep things as simple as possible).
This reverts commit 7b76e39.
This reverts commit 7b76e39.
5 participants
Reverts #28003
Reverts #28360
@scheibelp and @varioustoxins have volunteered to maintain Python 2 support for me, so I'm fine with reverting this change. I will still deprecate Python 3.1 though since #28346 requires sysconfig which was introduced in 2.7/3.2. I may consider deprecating additional versions of Python 3.2-3.6 in the future if these versions become difficult to maintain. Unlike the change from Python 2 to 3, the change from 3.6 to 3.7 usually just involves deleting pre-cythonized files.