-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require Python 3.5 or later, dropping support for Python 2. #1955
Conversation
This change does not yet remove any of the compatibility for Python 2, but only aims to declare the dropped support.
In this latest push, I've added a new module,
I believe by dropping support for Python 2 and emitting this warning, this project should be able to suss out any use-cases that are rapidly and unexpectedly running the unsupported version on Python 2, allowing this pull request to be accepted today and for Python 2 support to be removed in short order (weeks, not months). |
…e with guidance on how to avoid the warning and what to do if that guidance was ineffective.
@jaraco Looking at this, it seems like this actually did drop support for Python 2. I thought we were just going to emit an annoying warning? I am sort of on the fence about even emitting a warning, but I don't really think we should drop Python 2 support without coordinating with other PyPA packages. Especially I think maybe what we should do is to get this on the agenda for the Packaging Summit and discuss overall strategy there. I don't think an extra 4 months of Python 2 support will be a huge problem for us. |
Right - I did drop declared support for Python 2, without dropping the compatibility layers. This means that installers using pip will get It will enable the project to solicit feedback on use-cases that may not be supported, but also set the stage to eliminate the compatibility layer. If pip needs Python 2 support, they can pin to My hope is this change will be mostly automatic, and there will be few or no issues and we can simply move forward to the future.
I spent several hours recently working through issues due to Python 2 for an issue that had a straightforward implementation on Python 3. Is that a huge problem? Perhaps not, but by the same measure, retaining Python 2 support indefinitely wouldn't be a huge problem, just a perpetual annoyance that's a drag on the project and limits innovation. If there's significant harm in this change, we can revert it. |
Without testing for compatibility, compatibility will degrade by random bit-rot. Also, this PR does not address my major concern with dropping Python 2 which is that I don't think we should be encouraging people to pin
I get that it's annoying to continue supporting Python 2, but as I've said in several places, I am worried that this is going to hurt adoption of I vote for reverting it. |
True. I've been thinking about this concern. I'm tempted to create a test environment that tests Python 2 compatibility, but I thought I'd defer that effort until it's needed. I think there's a not insignificant chance that it won't be needed. The fact that any testing is not part of CI now is an issue and a risk, I agree.
I agree. And I don't think this change necessarily encourages pinning. The baseline expectation is that with pip 9 or later, no pinning is necessary and everything continues to work.
Acknowledged. And it's possible to selectively backport those changes to 44.x, while at the same time strengthening the incentive to move away from
I don't yet see a compelling reason to revert it, other than the risk of bit rot. On the other hand, reverting this now would create a lot of noise. My intention was to give this a trial run and see how it goes; should we not at least gather some data about the impact of this change? |
We can't make any breaking changes to the 44.x branch and keep with semver, for example, which means no hard removals of any of our deprecated commands. Admittedly, that's less important to me than the other stuff, though. That said, it is way more work to maintain a system of backports than to continue maintaining compatibility.
Yeah, I don't think you should have merged this and I definitely don't think you should have released it. I am aware that I have been slow on reviews and stuff, but I've tried to communicate that I was uncomfortable with moving quickly on this.
It seems unlikely that there will be immediate problems, but I also don't think a data-gathering period will be all that helpful for the problems I'm concerned about. No amount of a bunch of people pinned to a working version of In any case, what's done is done. I think this is going to cause problems in the long run no matter what we do now, because we'll probably cause confusion about when we are and are not dropping Python 2 support if we flip-flop back and forth. Might as well leave it like this for at least a week or two. I'd also like to hear more feedback from other PyPA projects as well. Maybe my concerns are overblown. |
As owner of virtualenv I'm committed to support it on cpython 2 for the next 18 months or so, and as I'm aware pip similarly 🤷♂️tox probably will drop with next major version is 6 months. |
Please don't feel bad; I'm trying to be fearless and push things forward with a reasonable level of caution. If it was disrespectful of me to launch this without another ping, I apologize. I probably am much less patient with the system, given that I got into distribute/setuptools maintenance over a decade ago in order to support Python 3 (and supersede Python 2).
:/ If those problems emerge (including lots of people pinning to Setuptools < 45), we can readily release a new version of Setuptools with a clear message that we're bringing back support for Python 2.
I'm hoping that most pinning is selective (on Python 2 only) if at all. I get what you say about the implicit pin.
I'm less sure about this concern. Much like CPython did, the Setuptools project can now selectively backport only those features that the team deems necessary for long-term support, and can sooner than later remove the compatibility layers in master. If the backporting gets too onerous, we can readily restore Python 2 support in master. |
For whatever it's worth, I do think that this is premature. Obviously I'm not a setuptools maintainer so take my opinion here with a grain of salt. I've generally been a big fan of data based decisions, so looking at what data I have available to me, in the last month, 58% of setuptools downloads from PyPI were for Python 2.7. So what this is effectively saying is that for let's say roughly half of setuptools users, they cannot use any new feature of the packaging ecosystem if they use setuptools for their build system. This has larger implications across the entire ecosystem, it's also telling every project out there that uses setuptools for it's build system that they have to also drop support for Python 2.7, or they have to pin to a version that does support Python 2.7, or they have to play the same kind of game we've done with Python 2/3 and figure out what subset of options works the same across the 2.7 supporting and the 3.x supporting versions of setuptools. All in all, I think for a project like setuptools (and pip, etc) it does far more harm to our users to drop support for 2.7 than the cost of keeping compatibility warrants. |
@@ -35,8 +35,6 @@ classifiers = | |||
Intended Audience :: Developers | |||
License :: OSI Approved :: MIT License | |||
Operating System :: OS Independent | |||
Programming Language :: Python :: 2 | |||
Programming Language :: Python :: 2.7 | |||
Programming Language :: Python :: 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's an additional Python :: 3 :: Only
classifier that can be useful setup-cfg-fmt can add it automatically based on python_requires
Current changes are breaking some of our builds with the following error (not warning):
Only resolution we have for this is to pin to <45 AFAIK FWIW our app actually uses python3, but we are building for a platform that uses python2 as the system python.
|
@kdelee First, sorry for the breakage; we were aiming for this release not to break things in the general case. It looks like you've run into an issue where you're using some one tool that doesn't honor Python-Requires to resolve/download setuptools, but then using pip to install it, so Python-Requires isn't honored for the first step, but then is enforced in the second step. I think you have several options.
Please help me understand the impact - does Setuptools provide the necessary tools for you to navigate this transition? In particular, does this affect new releases or does it also affect existing releases of your app? I had hoped for this change to require minimum intervention, so let me know if you don't have a straightforward way to address the concern, and in particular, what steps you run that lead you to this consequence. |
short story: we are going to pin on long story: trying to get one of our more build-focused devs (I'm just the one who found out the build was broken) to try and give you a more detailed response. |
This change broke Tahoe-LAFS CI for several platforms with older virtualenv/pip. I've put up a PR for Tahoe-LAFS to pin setuptools 44 - tahoe-lafs/tahoe-lafs#676. |
I looked into this, and here's what is happening:
Your suggestion to pin setuptools is probably the most expeditious at this point. Since you're using wheelhouse, you could also avoid putting setuptools >= 45 in the wheelhouse. |
This change does not yet remove any of the compatibility for Python 2, but only aims to declare the dropped support.
Closes #1458