Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecate poetry self commands #7872

Closed
wants to merge 1 commit into from

Conversation

dimbleby
Copy link
Contributor

@dimbleby dimbleby commented May 3, 2023

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@johnthagen
Copy link
Contributor

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

@dimbleby
Copy link
Contributor Author

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
Copy link

mjam03 commented Jun 8, 2023

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Member

Secrus commented Mar 20, 2024

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.

@Secrus Secrus closed this Mar 20, 2024
@dimbleby
Copy link
Contributor Author

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

@dimbleby dimbleby deleted the deprecate-poetry-self branch March 21, 2024 22:39
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants