Drop support for Python 2.7

[jaraco]

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]

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

[jaraco]

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]

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]

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]

@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]

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]

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)