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.

[caniko]

@remram44, ~where is the~ what is so bad about virtue signaling? I don't find your way of critique very helpful, in fact it just escalates the issue and alianates everyone but those that are in your echo-chamber. How am I supposed to critique your toxic feedback without using ideals, aka what you call the act of virtue signaling? Also virtue signaling is loaded with negative history, why would you ever use that term in good faith?

This is the video, and I think it is pretty good. I disagree on almost every conclusion, but it is very insightful to the frustrated side of this discussion.

Hypothesis/Hot take Sarcasm with no remorse indicates your lack of rationalle towards counterarguments in this context. Back to my initial diagnostic of this being an attack on your freedom and power as developer; the issue is emotional rather than rational for you; perhaps most of you.

If you want my humble opinion I think the brown-out was an OK solution. You shouldn't use an unsupported/outdated install method in production. Are there better ways to signal this, maybe. Should the devs care about the health of the product or the quality of life of the endusers, the answer is somewhere in between.

I think a post-mortem of the situation is good for the community. People brush away bad experiences without providing constructive feedback to the other side, which I think is a lost of opportunity for improving the quality of collaboration and communication within the community.

@neersighted apologies for bothering you initialy, I coudln't find this thread and thought it would be OK to post in the other thread. The issue seems to have been solved now that the PR is locked.

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

[remram44]

(thread becomes hard to follow because comments were apparently moved between issues)

@caniko: I am not "escalating" anything, since I have not posted a single comment in over a month. I am not trying to engage, please stop posting comments in closed issues and mentioning me. The situation has been resolved thanks to the changes by the maintainers. Stop spamming my inbox.

[caniko]

Excuse me @remram44, you mentioned me first... I wasn't directing any part of my initial comment at you.

Also, I don't think I said escalation was your intention, it is your language that is escalating—food for thought.

Please don't be patronizing, I can post whereever I want to, as long as I am authorized to do so.

I'll stop mentioning you.

[remram44]

This is very childish. I have asked you to stop @-mentioning me across two separate tickets, stop mentioning me to tell me how you'll stop and it's all my fault anyway. Just stop.

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

https://github.com/python-poetry/poetry/blob/7c86992909257caa4f51a50c001f5894bfe5065e/docs/_index.md?plain=1#L184-L190

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 901bdf04, 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:

https://github.com/python-poetry/poetry/blob/7c86992909257caa4f51a50c001f5894bfe5065e/docs/_index.md?plain=1#L184-L190

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[bot]]

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.