Removal of get-poetry.py

[neersighted]

This issue tracks the removal of get-poetry.py from this repository. After discussion triggered by the release of 1.2.0, and an attempt to bring awareness to the deprecation of this script, it has been decided that we will remove get-poetry.py from this repo on or after January 1, 2023.

A PR that changes get-poetry.py to have the following flow will be merged:

• When run without an explicit version, 1.2.x will be selected (as it is the latest) and the installer will fail as it cannot install 1.2.0a1 or newer.
• Any explicit version can be selected, and the installer will succeed for versions it understands.
• If GET_POETRY_IGNORE_DEPRECATION=1 in set the environment, the latest installable version will be used even when no explicit version is selected.
• In all cases a deprecation message will be printed, and warnings will be issued when uninstallable versions of Poetry are skipped.
• A target removal date of January 1, 2023 will be printed, with a link to this issue, and a blog post linking here as well.

The get-poetry.py script is considered frozen, and will not receive fixes if it is broken by external factors.

For previous discussion of this process, see #6314.

[neersighted]

For those following along at home, the PR is merged and the above behaviors are accurate for get-poetry.py. No more changes are planned for this script before removal.

[BurekPrime]

@neersighted
I would like to ask you if changing:
curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -
to:
curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/901bdf0491005f1b3db41947d0d938da6838ecb9/get-poetry.py | python -
will still work after 01.01.2023?

To give some context I develop a platform that is scheduled to be closed, somewhere in February 2023 and all of our Python component build pipelines depend on the old install script still working (they broke, but after your fix they are working again, so thank you for that). I'm only interested in the poetry installation working up util then (in case of some hot fix release) and don't want to introduce to much changes. Can I count that the master branch won't be rebased or something and that the script from the commit will be still working? You mentioned that script can break due to "external factors", could you please elaborate.
Sorry if I picked up a wrong channel for such question, but I'm not aware of a more appropriate place.
Thanks for the answer in advance.

[neersighted]

The commit will remain in history -- Poetry as a project has a linear history and we do not rebase or drop commits from the stable/protected branches. In short: you will be able to keep using the script from that URL indefinitely.

When I refer to external factors, I mean any changes in common external components (Python, pip, your operating system or distro's packaging thereof, etc.) -- we don't plan to make any changes even if something somebody else changes causes the script to not function.

[BurekPrime]

@neersighted Thank you for such a great and quick answer.

[neersighted]

As far as I am concerned, it's a tempest in a teapot and not worth fixating on. To highlight the situation:

• get-poetry.py was replaced 18 months ago.
• get-poetry.py was considered deprecated (and emitted warnings) for the last 12 months.
• It correctly warned that versions >=1.2.0a1 could not be installed.
• When one ran get-poetry.py with no version, it would install the latest version as reported by PyPI.
• After 1.2.0 was released, this naturally became 1.2.0, breaking CI pipelines that did not specify an explicit version.

Several users reacted strongly to this, and made the case that they could not easily update their environment (due to change control) or that running the latest version was a strong feature for them.

The original ask/assertion was that get-poetry.py should install the latest version it understood, instead of the latest version. We (the maintainers) were willing to try and provide such an escape hatch, but only if we balanced this sudden and unexpected behavior change against these CI user needs.

The initial solution was to fail without an explicit version for interactive use (as it was asserted both installing the latest 1.1.x version as well as failing on 1.2.x were both unexpected/undesirable, and we were currently failing anyway), and to mostly succeed in CI to try to get users to understand they were using a deprecated script, and should set an environmental variable to acknowledge the change in behavior and write down the deprecation date for their teams.

However, after accepting this design and merging it, other users (as well some of us on the Poetry team, including yours truly) had second thoughts -- after all, this was a sudden behavior change in a script that had been stable for years. We decided to revisit the design, and landed on the present state of things -- essentially a revert to the prior state where get-poetry.py will fail on 1.2.x, but with a more detailed message explaining why, and pushing --version as the escape hatch. For those users who are unable/unwilling to specify a fixed version number, we kept GET_POETRY_IGNORE_DEPRECATION as an escape hatch for 'make things as they were pre-1.2 release.'

This was a bit of an unexpected mess as we had thought that due to the year-long messaging, users who were still on get-poetry.py would have an explicit --version set at this point. Obviously that was false -- the main takeaway has been the need to find more channels to communicate incoming deprecations of this magnitude in the future, as well as to repeatedly amplify important messaging to users. As such we've started compiling a list of additional channels to use (beyond our blog, Discord, and release notes) such as Twitter, other popular Python Discord servers, Reddit, etc.

Deprecations are going to be increasingly a part of Poetry development as we try to accelerate development, fix UI quirks, design flaws in the project format, etc. If you are someone who believes they have a lot of experience in designing, implementing, and communicating deprecation cycles, I would encourage you to get involved with Poetry development -- we always need more people, especially subject matter experts on the team.

I would also request that people stop sending me rude emails (though I expect that those who are doing so will not read this issue -- I can only hope they click through from the linked PR). I am sorry that decisions made by Poetry ruined your week at work, but we're all voulenteers doing our best for the health of the project and our own sanity. If you want to see increased "competence" and "responsibility" upstream, sending negative emails to me or other maintainers will have the opposite of the desired effect.

[neersighted]

I am hesitant to lock this thread as I do believe that discussing how we handled this (as well as any necessary further clarification about this change/process), and how to move forward can be valuable. However, it is clear that tempers are still running high, and the Youtube video/Twitter comments are likely the reason for it (they seemed to coincide with emails, and comments here). I will be locking this thread for now for the next week or so -- I hope that by then, clearer heads will have prevailed, and we can have a productive dialogue.

[Crosse]

Hi!

I think the docs need to be updated to reflect that this script has been removed, and perhaps give alternate instructions for uninstallation:

poetry/docs/_index.md

Lines 184 to 190 in 7c86992

	{{% warning %}}
	If you installed using the deprecated `get-poetry.py` script, you should use it to uninstall instead:
	```bash
	curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3 - --uninstall
	```
	{{% /warning %}}

I just happened to try to update a (clearly) seldom-used install of Poetry this morning and ran across this. I solved my issue by downloading the script at commit 901bdf0, as mentioned in a comment above, so this is more an FYI than anything else.

[sebastianfelipe]

Hey folks! Is this GET_POETRY_IGNORE_DEPRECATION=1 env used after the change in the installation process? Thanks!

[Secrus]

Hey folks! Is this GET_POETRY_IGNORE_DEPRECATION=1 env used after the change in the installation process? Thanks!

No. This control variable was introduced only in the removed get-poetry.py script.

[ak-empiak]

Hi!

I think the docs need to be updated to reflect that this script has been removed, and perhaps give alternate instructions for uninstallation:

poetry/docs/_index.md

Lines 184 to 190 in 7c86992

	{{% warning %}}
	If you installed using the deprecated `get-poetry.py` script, you should use it to uninstall instead:
	```bash
	curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3 - --uninstall
	```
	{{% /warning %}}

I just happened to try to update a (clearly) seldom-used install of Poetry this morning and ran across this. I solved my issue by downloading the script at commit 901bdf0, as mentioned in a comment above, so this is more an FYI than anything else.

If someone needs the command : curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/901bdf0491005f1b3db41947d0d938da6838ecb9/get-poetry.py | python3 - --uninstall

[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.