pipx upgrade fails when package is not installed

[jorhett]

Describe the bug

The documentation at https://pipx.pypa.io/stable/docs/#pipx-upgrade says that upgrade is:

Upgrade a package in a pipx-managed Virtual Environment by running pip install --upgrade PACKAGE

pipx upgrade fails when a package is not installed, so that is not the behavior.

How to reproduce

$ pipx --version
1.4.3

$ pipx --verbose upgrade dummy_test
Package is not installed. Expected to find /Users/example/.local/pipx/venvs/dummy-test, but it does not exist.

It should have installed it if not installed, and upgraded it if installed.

[jorhett]

It would appear that a long form of install --pip-args='--upgrade' is the workaround, but this wasn't necessary in the past so this is a breaking change.

[Gitznik]

Hi @jorhett, thanks for raising this. From a quick investigation I can see that the code leading to this behavior has not been changed in the last 4 years. Do you have a rough idea in what version of pipx the workaround was not necessary?

The documentation at https://pipx.pypa.io/stable/docs/#pipx-upgrade says that upgrade is:

Upgrade a package in a pipx-managed Virtual Environment by running pip install --upgrade PACKAGE

pipx upgrade fails when a package is not installed, so that is not the behavior.

I can see how the wording here is imprecise. The code indeed runs pip install --upgrade PACKAGE, but only if the package is already installed. Else, the exception you see is raised.

I you can help pointing me to a version of pipx since 1.0 where this was not the case I'm happy to mark this as a bug. Otherwise, I'd suggest treating it as a feature request.

[jorhett]

I don't know what version. All I know is that an Ansible role I'd created to install and update packages is now failing, and looking at previous test history it succeeded with the upgrade action. We haven't changed the role in ~2 years and we only run tests on changes to our role, so unfortunately I don't know when it broke.

I you can help pointing me to a version of pipx since 1.0 where this was not the case I'm happy to mark this as a bug. Otherwise, I'd suggest treating it as a feature request.

It seems a bit disingenuous to say that "not doing what the documentation says" is a feature request, no?

Whether you consider it a bug or a feature, it's definitely needed since there is no machine-parseable way to test to see if pipx has already installed the package.

[uranusjr]

I would say something like pipx upgrade --install <pkg> would satisfy this better.

[chrysle]

I would say something like pipx upgrade --install <pkg> would satisfy this better.

I can have a look at implementation details, if you all agree.

[Gitznik]

I don't know what version. All I know is that an Ansible role I'd created to install and update packages is now failing, and looking at previous test history it succeeded with the upgrade action. We haven't changed the role in ~2 years and we only run tests on changes to our role, so unfortunately I don't know when it broke.

Gotcha. Maybe my suggestion at the very bottom can help you quick fix your pipeline.

It seems a bit disingenuous to say that "not doing what the documentation says" is a feature request, no?

It's splitting hair, but as I mentioned, it does do what the documentation says, but it first checks if the package is already installed.

Whether you consider it a bug or a feature, it's definitely needed since there is no machine-parseable way to test to see if pipx has already installed the package.

There is pipx list --json | jq -e '.venvs|keys[]|select(. == PACKAGE)', but I agree, a more ergonomic solution would be nice.

[Gitznik]

I would say something like pipx upgrade --install <pkg> would satisfy this better.

I can have a look at implementation details, if you all agree.

pipx upgrade currently does not allow specifying the python interpreter to use (which makes sense). I think adding it would be somewhat confusing as well. Maybe pipx install --upgrade makes more sense because it would provide the correct arguments and is also closer to the pip syntax?

[chrysle]

Maybe pipx install --upgrade makes more sense because it would provide the correct arguments and is also closer to the pip syntax?

This was rejected by @uranusjr and @gaborbernat in the past, but maybe they find this reasoning strong enough to unblock the feature.

pipx upgrade currently does not allow specifying the python interpreter to use (which makes sense).

That infrastructure could be added without much effort, as far as I can tell.

[Gitznik]

pipx upgrade currently does not allow specifying the python interpreter to use (which makes sense).

That infrastructure could be added without much effort, as far as I can tell.

Yes I don't think it's hard to add, just that it's potentially confusing to be there. the argument would only be relevant in combination with the --install flag. I think having --upgrade on pipx install would be less confusing.

[uranusjr]

The Python interpreter issue goes both ways. If an application is already installed, what should pipx install --upgrade --python=... do if the interpreter does not match? I can see arguments from both sides and neither is wrong (or right).

[chrysle]

I think having --upgrade on pipx install would be less confusing.

While that would make the pipx upgrade command potentially useless / unpopular, and that was a considered design decision for pipx.

[Gitznik]

Fair enough, let's go for pipx upgrade --install then 👌

[jorhett]

There is pipx list --json | jq -e '.venvs|keys[]|select(. == PACKAGE)', but I agree, a more ergonomic solution would be nice.

That does not by itself confirm that a package is installed. You also need to compare that list. Likewise deep into the details, but hard to use in configuration management systems aiming for idempotence.

On the matter of which argument to support, it seems that aligning with pip would be cleaner on the user experience. However this point is relevant:

The Python interpreter issue goes both ways. If an application is already installed, what should pipx install --upgrade --python=... do if the interpreter does not match?

If this makes it easier to implement, 👍