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)

[jaraco]

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?

[noahlz]

This is helpful, thank you!

[soumya-devops]

Hello , we are using python 2.7 , pip version 20.0.2 and setuptool version is 45.1.0 but getting the below warning message .

/usr/lib/python2.7/site-packages/pkg_resources/py2_warn.py:22: UserWarning: Setuptools will stop working on Python 2

---

You are running Setuptools on Python 2, which is no longer
supported and

SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release (no sooner than 2020-04-20).
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
#1458
about the steps that led to this unsupported combination.

---

pip -V
pip 20.0.2 from /usr/lib/python2.7/site-packages/pip (python 2.7)

As you can see the pip version is greater than 9.x but still i am getting the warning.

do we need to downgrade SETUPTOOL < 45.

[jaraco]

@soumya-devops Maybe.

Here's the order of preference for how you should approach the issue:

1. Upgrade your application to run on Python 3. Although I recognize that this work may be impractical in the short term, it's the only long-term solution.
2. Make sure you're installing Setuptools with a late version of pip. It's not enough to have pip 9.x; you must also use that version of pip to install setuptools. If pip 9.x or later is installing setuptools 45, that's unexpected.
3. When building your environment, ensure that setuptools < 45 is installed in advance, so it's satisfied when it's installed by something else.
4. After building your environment, uninstall and reinstall setuptools to ensure a suitable version is installed.

If this advice doesn't solve your issue, please file a new bug describing what you've tried and how you end up with an unexpected (incompatible) version of setuptools. Please try to include any details will allow someone else to replicate the issue, such as the commands you ran and the output they gave.

[Lovewyrm]

I know nothing about python, but I have to use it like a chimpanzee right now.
How do I suppress this from within the script I'm using?
I really don't want to set up an evironment variable for this horsedookie.

Thanks.
P.S.:
I am using setuptools 45.2.0, at least that's the version of my distros (Slackware) package.
Edit: And running pip2 list
Plz halp oh god this is horrible ahhhh.

P.P.S.: Solution for now:

import warnings
warnings.filterwarnings("ignore")

[jaraco]

How do I suppress this from within the script I'm using?

Essentially, ensure you're using setuptools<45. You can do this by only installing setuptools with a late version of pip (>9.x) or otherwise specifying pip install 'setuptools<45'.

Solution for now [is to suppress warning]

I wouldn't recommend suppressing warnings, as eventually setuptools will drop code compatibility for Python 2.7 and the error will become a crash.

If this isn't enough to help, please open a new issue describing the steps you use to create your environment where you're getting the incompatible version of setuptools.

[eli-schwartz]

I am using setuptools 45.2.0, at least that's the version of my distros (Slackware) package.

If you're getting python2-setuptools via your distribution package manager channel, you should probably ask the Slackware developers to roll back their build recipe. That is what we (Arch Linux) did for our distribution setuptools package. We have pinned it to 44.0.0

[eldu]

I am using pip==20.0.2 setuptools==45.2.0 and still got the following message:

app_1 | ************************************************************
app_1 | You are running Setuptools on Python 2, which is no longer
app_1 | supported and
app_1 | >>> SETUPTOOLS WILL STOP WORKING <<<
app_1 | in a subsequent release (no sooner than 2020-04-20).
app_1 | Please ensure you are installing
app_1 | Setuptools using pip 9.x or later or pin to setuptools<45
app_1 | in your environment.
app_1 | If you have done those things and are still encountering
app_1 | this message, please comment in
app_1 | #1458
app_1 | about the steps that led to this unsupported combination.

[MarenRobers]

Hallo, I was trying to run a shadow hand simulation. I am running Ubuntu 16.04, ROS Kinetic, pip 20.0.2 and setuptools-45.2.0and get the following error:

************************************************************
You are running Setuptools on Python 2, which is no longer
supported and
>>> SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release (no sooner than 2020-04-20).
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.
************************************************************

[jaraco]

Hi @MarenRobers . Sorry to hear you're having trouble. In order to solicit better details about these issues, I've created https://bit.ly/setuptools-py2-warning and future versions of setuptools will direct users there to file a report about their Python 2 compatibility issues. Please follow that link (or simply complete the relevant template) to create a separate issue relating to your environment. I'm going to lock this thread so that others get this same guidance.