Skip to content
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

Drop support for Python 2.7 #1458

Closed
jaraco opened this issue Aug 16, 2018 · 9 comments · Fixed by #1955
Closed

Drop support for Python 2.7 #1458

jaraco opened this issue Aug 16, 2018 · 9 comments · Fixed by #1955

Comments

@jaraco
Copy link
Member

@jaraco jaraco commented Aug 16, 2018

It's possible we already have a ticket for this, but #1457 revived the idea. Here are my thoughts:

I'm interested in dropping support for new releases on Python 2.7. I can imagine maintaining support for Python 2.7 in a bugfix-only branch. My main worry would be breaking the expectation that the latest version of setuptools is generally viable in all supported versions. But there are features now that would mitigate that issue -- the python_version declaration and PEP 518 support in pip, I'm thinking systems admins and app developers would still be able to install the "latest" version of setuptools, even in Python 2.7, but they would only get the maintenance versions. Presumably the same thing happened for Python 2.6. I'd really like to drop support for Python 2.7 earlier than later if possible.

@busunkim96

This comment has been minimized.

Copy link

@busunkim96 busunkim96 commented Aug 13, 2019

Hello @jaraco! Apologies if this is documented somewhere else. Are there any additional plans for dropping Python 2.7 support?

@jaraco

This comment has been minimized.

Copy link
Member Author

@jaraco jaraco commented Aug 14, 2019

In the brief discussions I've had with others, I get the sense there are too many environments that would break if setuptools were to drop Python 2 support. In many ways, setuptools is at the base of the dependency tree so will have to be the last package to drop support.

@hugovk

This comment has been minimized.

Copy link
Contributor

@hugovk hugovk commented Aug 14, 2019

Pip is in a similar boat, see pypa/pip#6148 and for packaging in general see https://discuss.python.org/t/packaging-and-python-2/662.

@jaraco

This comment has been minimized.

Copy link
Member Author

@jaraco jaraco commented Jan 2, 2020

I'd like to revive consideration for this issue, not because it's Jan 2020 as much as that I spent several hours yesterday addressing Python 2 support in this codebase.

Let's say we were to summarily drop support for Python 2.7 today - what impact would that have? Projects using pip 9 or later to install setuptools would not be affected (they'd continue to get compatible, if frozen, versions). Only projects using easy_install or some other mechanism (e.g. from GitHub master) for installation might be affected.

That seems perfectly reasonable to me.

@pganssle

This comment has been minimized.

Copy link
Member

@pganssle pganssle commented Jan 2, 2020

@jaraco I tend to agree in some ways, but I think @dstufft's comment from the discourse thread is on point (as usual):

My general opinion is that the packaging toolchain needs to be conservative in dropping support for packaging and installing packages on Python 2 and use a usage based methodology for deciding when to drop support for that.

The main underlying reason is that I think it will hamstring our ability to continue to improve Python’s packaging. Obviously someone has to upgrade the versions of the relevant tools in order to get support for new features. However if a project is supporting 2.7 for one reason or another then they are going to be stuck using only the features that existed in the 2019 era toolchain unless we go to great lengths to make sure that all new standards degrade gracefully.

As much as I would love to say that we should drop it today, the natural consequence of us dropping Python 2 support is that projects still supporting Python 2 won't be able to use new features we support. What that means is that all the projects right now who aren't adding pyproject.toml support because it's missing some critical feature (e.g. editable install support) won't be able to adopt it without also dropping Python 2.

I see pyproject.toml and adoption of other modern packaging features as higher priority than dropping Python 2 compatibility at the moment. I say that we wait until a significant fraction of packages have dropped Python 2 entirely or until we are confident that pyproject.toml builds are sufficiently "feature complete" that we won't expect a feature freeze on the Python 2 branch to hinder adoption rates.

@pganssle

This comment has been minimized.

Copy link
Member

@pganssle pganssle commented Jan 2, 2020

One other thing to note: when we do go for the Python 2 drop, we should probably advertise it with enough advance notice that it can be a meaningful driver of people's behavior. If we make big enough fanfare about it and give people 6 or 9 months' notice, we may be able to induce marginal holdouts to drop Python 2 entirely.

If we do it suddenly without prior announcement, I think people will scramble to get workarounds in place and then find that the workarounds are "good enough".

@noahlz

This comment has been minimized.

Copy link

@noahlz noahlz commented Jan 13, 2020

Hello we are using Python 2.7 and seeing a scary message every time we invoke supervisorctl which is 100s of times in our deploy process. We are working feverishly to move our java application off Supervisor to containers, but in the meantime we need to understand the risk here - will our deploys stop working? We have the following versions of packages:

#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'setuptools==20.6.4','console_scripts','easy_install'
__requires__ = 'setuptools==20.6.4'
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.exit(
        load_entry_point('setuptools==20.6.4', 'console_scripts', 'easy_install')()
    )
$ pip -V
pip 1.5.6 from /usr/local/lib/python2.7/dist-packages (python 2.7)

Warning message:

/usr/local/lib/python2.7/dist-packages/pkg_resources/py2_warn.py:19: UserWarning: ************************************************************
You are running Setuptools on Python 2, which is no longer
supported and
>>> SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release. Please ensure you are installing
Setuptools using pip 9.x or later or pin to `setuptools<45`
in your environment.
If you have done those things and are still encountering
this message, please comment in
https://github.com/pypa/setuptools/issues/1458
about the steps that led to this unsupported combination.
************************************************************
  sys.version_info < (3,) and warnings.warn("*" * 60 + msg + "*" * 60)
@jaraco

This comment has been minimized.

Copy link
Member Author

@jaraco jaraco commented Jan 14, 2020

scary message ... 100s of times in our deploy process

O_O

will our deploys stop working?

The short answer is yes, but it's possibly more complicated.

I see you have pip == 1.5.6, which was released on May 2014, suggesting you have a very old Python environment (stack) installing a much newer Setuptools. I would suggest a few options to investigate and prevent the breakage.

  • Search your stack for where setuptools is being installed/upgraded and change it to only install setuptools<45.
  • In your stack, upgrade pip to 9.x or later and only ever install Setuptools with that version of pip (you'll still need to downgrade setuptools for existing environments).
  • Push ahead with your migration to containers before Setuptools starts breaking on Python 2.7.

I'm not sure when Setuptools will start breaking on Python 2.7, but it will be at least a few months, and no sooner than Apr 20. If you are electing to just ignore the warning, you can suppress it with an environment variable PYTHONWARNINGS=ignore:::pkg_resources.py2_warn (perhaps there should be a better way to reference this warning).

Does that help?

jaraco added a commit that referenced this issue Jan 14, 2020
…eamble to make referencing the warning more reliable. Ref #1458.
@noahlz

This comment has been minimized.

Copy link

@noahlz noahlz commented Jan 14, 2020

This is helpful, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.