Deprecate Python 3.6

[tony]

Python 3.6 has reached end of life last month on December 23rd, 2021.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Issue

Since Python 3.6 support has officially ended, 3.6 compatibility can be removed throughout the codebase (including CI, docs)

[finswimmer]

Hello @tony,

we've discussed this already within the Poetry team and everyone likes to drop python3.6. According to pypistats there seems to be ~5% that are still using python3.6. This is why we haven't made a final decision until now.

fin swimmer

[tony]

@finswimmer WIP:

• Deprecate Python 3.6 poetry-core#263

P.S. Can I have my username automatically approved for CI runs?

[tony]

@finswimmer Should we keep this issue open for python-poetry/poetry-core#263 and python-poetry/install.python-poetry.org#11?

poetry-core's issue tracker redirects back to poetry's: https://github.com/python-poetry/poetry-core/issues/new/choose

[markus-oberhumer]

Chiming in late, but are there any technical reasons for not supporting Python 3.6 any longer?

Red Hat Enterprise Linux 8 (RHEL8) and all it's clones (like Alma Linux 8, Rocky Linux 8) use Python 3.6 and will be supported until May 2029 (and therefore will get fixes / backports from Red Hat), and as this is a really widespread Linux distribution this change does affect millions of servers.

[tony]

@markus-oberhumer Good point

Red Hat Enterprise Linux 8 is distributed with several versions of Python 3. Python 3.6 is going to be supported for the whole life cycle of RHEL 8. The respective package might not be installed by default.

above: 15.1.1.1. Python 3 is the default Python implementation in RHEL 8

I think it is worth making a new issue and citing this if python 3.6 deprecation could disrupt things on your end. I'm concerned this won't be seen since it's already closed.

caveat, poetry isn't the only package dropping support for python 3.6:

• setuptools v59.7.0+ drops python 3.6 (pypa/setuptools@340d0e0)
• pip 22.0+ drops python 3.6 (pypa/pip@0252c04)

On the other hand, requests and virtualenv still support python 3.6 at the time of this comment.

[markus-oberhumer]

Well, pip and setuptools (as well as requests and virtualenv) are official RHEL8 packages, so these are conveniently handled by the distribution.

Unless there are some technical reasons it might worth considering restoring Python 3.6 compatiblity.

$ rpm -q python3-pip python3-requests python3-setuptools python3-virtualenv
python3-pip-9.0.3-22.el8.noarch
python3-requests-2.20.0-2.1.el8_1.noarch
python3-setuptools-39.2.0-6.el8.noarch
python3-virtualenv-15.1.0-21.module_el8.5.0+895+a459eca8.noarch

[tony]

@markus-oberhumer I think the next step would be to raise this concern in a new issue (referencing the comments we had here)

[finswimmer]

Hello @markus-oberhumer,

we are simply not enough people to support dead python versions. It's time consuming to work around things that doesn't work in older python versions. Furthermore it holds us back to improve poetry if we cannot use new python features.

We didn't write it anywhere until now, but between the maintainers there is an agreement, that we will promise to support a python version until it's end of life. After that we can drop the support at any time.

fin swimmer

(Personal opinion: The date when the end of life of a software is reached, doesn't mean "start transition", it means "end of the transition period")

[markus-oberhumer]

@finswimmer I fully get your point - just wanted to make sure you are aware of the consequences, esp. as there seem to be no real technical reasons for this decisions ATM.

[abn]

Just to add to what @finswimmer already mentioned, the primary motivator here is to reduce the maintanence burden imposed by keeping features working in older versions of Python.

While I understand that there is LTS offerred by various distribution vendors for Python 3.6 and even 2.7, this happens due to resources being allocated specifically for this task, ie by the likes of Red Hat. The drop of support here only relates to the runtime version of Poetry and not the version of Python environments Poetry manages. And also consider that these distributions also provide newer versions of Python to be installed alongside system default versions.

As for technical rationale, there are a few projects within Poetry's dependency chain that have dropped support for older Python versions. So, we can either keep them locked to older (and unsupported) versions or try maintaining/backporting fixes and improvements. That is a, very deep rabbit hole. And if this level of support is required by someone, I'd suggest that you pay a vendor. Since Poetry 1.1 versions still support these versions of Python, a vendor could in theory backport fixes/improvements to a supported fork.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.