RFC: Packaging 21+ and dropping support for managing Python 2.7 environments

[neersighted]

Time marches on, and the EOL for Python 2.7 is nearly two years in the past. While Poetry 1.2 (which drops support for Python 2.7/3.5) is not yet out of alpha, we have one more additional wrinkle to consider regarding Python 2.7.

Namely, Poetry intended to keep supporting management of Python 2.7 environments, even if it required Python 3.6+ to run. However, due to upstream changes in Packaging that we want to be able to track, it looks like we are going to be unable to fulfill that promise going forward.

Issue #4264 is tracking support for more modern Packaging versions -- to fix this issue/follow upstream, we will have to drop support for Python 2.
PR #4749 implements support for more modern Packaging versions by both bumping the version constraint as well as adapting to changes in upstream's package layout.

Given the time that has gone by since the official end of Python 2.7 support, I'd like to collect feedback on the idea of dropping Python 2.7 management in the next alpha release. To do so, we would simply merge #4749.

Users who still require Python 2.7 support will be able to fall back to the 1.1.x line of releases (currently 1.1.11) which will continue to support Python 2.

[gunungpw]

I think it's reasonable for poetry to drop support python 2.7, because lack of man power/maintainer or little interest from user base itself. If no one from maintainer or user want to maintain the part regarding python 2.7, this change was the best decision from the perspective of maintainability for poetry going forward. Also pip itself closing issue regarding python 2 related problem as won't fix no action.

Thanks, maintainers and contributors of Poetry, I love this project.
Hope you all have a nice day

[abn]

@neersighted a quick search on source graph says there are around 234 projects out there that reference python 2.7.

https://sourcegraph.com/search?q=context:global+file:pyproject.toml+%28content:%22python+%3D+%5C%22%5E2.7%22+OR+content:%22python+%3D+%5C%22%7E2.7%22+OR+content:%22python+%3D+%5C%22%3E%3D2.7%22%29+-repo:%5Egithub%5C.com/python-poetry/.*+&patternType=literal

Removing tests, vendored packages etc. that goes down to 167.

[Secrus]

IMO let the dead remain dead. Python 2.7 is not supported for some time now and if you ask me, the less support in tooling it has, the more reason for projects to migrate to Python 3.x. Poetry has already a great amount of issues, lets limit them to 3.x only.

Same as gunungpw, I would like to thank all maintainers and contributors for their work on Poetry, I absolutely love it

[abn]

Given that Python 2.7 has been sunset over 2 years now, I think we should drop support for Python 2.7 projects. I suspect packaging is the first of many such cases that, if we retain 2.7 support, will add to the support burden for maintainers.

@neersighted unless anyone can raise a strong and justifiable arguments against this, let's proceed with dropping support for Python 2.7 projects. We can highlight the mitigations in documentations in case people really want the support.

Mitigations for those that really need Python 2.7 support

Further, it should be noted that, for now, it is possible for a user to workaround this doing one of the following if it is really desired to support a Python 2.7 project with Poetry.

1. Use upcoming poetry self add packaging@^20.9 to override the unclamped dependency on packaging>=20.4. (or via pipx).
2. Use a 1.1 release of Poetry. You can have multiple versions of Poetry available thanks to pipx install --suffix=@version.

Older Poetry projects should still build with poetry-core.

Potential routes to preserve Python 2.7 project support (not recommended)

For completeness, the following are options that can be implemented to preserve 2.7 support. However, all of these options come with additional maintanence burden.

1. For Python 2.7 environments, download a compatible version for the relevant file as .venv/tags.py or ~/.cache/pypoetry/tags27.py.
2. Create a Python 2.7 environment with just packaging==20.9 (preferably cached) and fetch file from here if the active environment is Python 2.7.

Personally, I reckon we should stop relying on an external dependency in this manner (eval(__file__)). Making the above options bandaids at best.

cc: @python-poetry/core @python-poetry/triage

[jcmdln]

I agree with @gunungpw that in order to retain Python 2.7 support in Poetry there would need to be both some interest in using Poetry with Python 2.7 as well as a commitment for someone to step up and maintain support. As @abn clarified above, documenting workarounds can allow impacted users to have some time to transition. I believe that a case could be made to provide a deprecation warning in Poetry before support for Python 2.7 is removed, as this could help to inform impacted users to make themselves known. This also depends on whether the Poetry maintainers feel this would be valuable, though I don't feel it's heavy-handed to drop support due to how long ago the Python 2.7 EOL was finalized.

My preference would be to update the docs to reflect the upcoming changes and move forward with deprecating Python 2.7 support without extended notice.

[Secrus]

I think, with new stuff coming in 1.2, it could be a good point for dropping 2.7 as well.

[abn]

I have cleaned up #4749 in preparation for this. I also have a patch ready if after release folks have complaints. Will need to follow up this PR with

1. Removal of Python 2.7 references in docs and tests.
2. Addition of error handling when poetry is targetting a 2.7 project.
3. Update docs to add explicit indication that Python 2.7 support is dropped.

[Secrus]

I have cleaned up #4749 in preparation for this. I also have a patch ready if after release folks have complaints. Will need to follow up this PR with

1. Removal of Python 2.7 references in docs and tests.
2. Addition of error handling when poetry is targetting a 2.7 project.
3. Update docs to add explicit indication that Python 2.7 support is dropped.

@abn I would be happy to help with that. Not sure about 2nd point (don't know codebase that well, could take some time), but 1 and 3 are for sure ones I can do.