deprecate `poetry self` commands

[dimbleby]

Of course I am not expecting this to be merged without some discussion! But I think it's a discussion that's worth having, so let's create a space in which to have it.

A thing that sometimes happens on this issue tracker is putting right users who have installed poetry itself in the project under management. Of course that goes wrong: among other things, running poetry update (or whatever) can cause packages to be updated while poetry itself is actively using them; if you get unlucky then poetry just won't work any more.

But so far as I can see poetry self commands all are built on this exact mistake: the poetry binary is managing its own environment. And indeed there are reports from people who do things like poetry self update and see just the same sort of problem: #7610, #7819

I don't understand how this can be expected to work, and I have no idea how it can be fixed.

What's more - perhaps this wasn't true a few years back - there are fine alternatives available, most obviously pipx based installations.

I also think in general that poetry has a larger surface area than is good for the health of the project - see the state of the issue backlog - and that poetry self is a relatively bug-rich part of the codebase, certainly compared to the value that it brings. So to my mind it's a great candidate for establishing that it is possible to remove code that is more burden than help.

Opinions welcome...

[johnthagen]

Would this effectively deprecate the official installer as well? Since poetry self update is the only way to update Poetry when installed that way?

[dimbleby]

The installer is perfectly capable of updating an existing poetry installation, poetry self update is not needed.

[johnthagen]

Okay, so would the workflow be to upgrade the officially installed Poetry that a user would go back to https://python-poetry.org/docs/#installing-with-the-official-installer, copy the command for their platform, and run it again?

To me, this would move me to use pipx instead to use a cross-platform way to update Poetry rather than use the official installer since the update process for the official installer would require a bit more work than poetry self update.

Note, I'm not saying that poetry self should or shouldn't be deprecated (I've had plenty of issues with poetry self update myself). Just wanted to discuss the knock on effects this could have.

(Slightly off topic) The bigger issue (not the Poetry dev's fault) is that Python really needs to bundle something like pipx in its official distribution to solve this bootstrapping issue for Poetry and other CLI tools. Rust does this with cargo install and NPM does this with npx, by being providing this by default.

I've brought this up to the core team before

• https://discuss.python.org/t/wanting-a-singular-packaging-tool-vision/21141
• https://discuss.python.org/t/wanting-a-singular-packaging-tool-vision/21141/24

[dimbleby]

pipx is a fine solution and the way that I install poetry myself. For users who want to do fancy things with plugins (which is not me) it would probably be a particularly good choice because pipx inject.

For those wanting to avoid pipx for whatever reason, running the installer both to install or upgrade seems fine.

There is no shortage of alternatives to poetry self update, and deprecating it need have no implications for the status of the installer.

[mjam03]

One thing that removing poetry self add might make quite tricky is adding plugins that allow poetry to be easily used with private repos utilising authentication (common inside industry). Maybe there is an easier way to do this but for example with my use case I have:

• private repos held in GCP artifact registry
• pyproject.toml with [tool.poetry.source] pointing to that repo location
• authentication s.t. poetry add <INTERNAL-PACKAGE> works after running poetry self add keyrings.google-artifactregistry-auth

If we remove the ability to do this then does that remove the ability to add plugins unless you have installed poetry in the first place using pipx (as stated here)?

And as such does that mean that if you want to install plugins then you'll need to not use the installer and pipx becomes the default for installation type?

[radoering]

Not sure if we should deprecate all self commands. poetry self show plugins for example still makes sense to me.

And as such does that mean that if you want to install plugins then you'll need to not use the installer

If you use the installer, you can still install plugins via pip as mentioned here.

and pipx becomes the default for installation type?

see #8090

[amp-matthew-wallace]

And as such does that mean that if you want to install plugins then you'll need to not use the installer

If you use the installer, you can still install plugins via pip as mentioned here.

Poetry's current documentation states that poetry self add poetry-plugin "...is the easiest way and should account for all the ways Poetry can be installed."

In my opinion, removing this simple option for installing plugins would be a step backwards in the usability of the tool. I have the same use-case as @mjam03 and also use Google Artifact Registry for private repos.

I don't have nearly enough context on the general issues with poetry self, so maybe this change can't really be avoided. I just think that having separate plugin install commands depending on how poetry is installed makes the tool more difficult to use.

[adam-grant-hendry]

In my opinion, removing this simple option for installing plugins would be a step backwards in the usability of the tool.

I second this

[Secrus]

Ok, I am going to wear my "maintainer" hat and make a decision on that. No. While I understand the self commands might be buggy, we should fix them instead of deprecating/removing.

[dimbleby]

fair enough - though

I don't understand how this can be expected to work, and I have no idea how it can be fixed.

remains true...

[github-actions[bot]]

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