Command line for notice update not copy-pasteable for venv

[roubert]

Description

When using venv and pip like this:

$ python3 -m venv test
$ test/bin/pip install […]
[notice] A new release of pip is available: 24.3 -> 24.3.1
[notice] To update, run: python3 -m pip install --upgrade pip

Then that command line isn't directly copy-pasteable, as it doesn't include the required path to the venv.

Expected behavior

It'd be more helpful if the command line was directly copy-pasteable, including the venv path (when needed).

pip version

24.3.0

Python version

3.12.7

OS

Linux

How to Reproduce

$ python3 -m venv test
$ test/bin/pip --version
pip 24.3 from /tmp/test/lib/python3.12/site-packages/pip (python 3.12)
$ test/bin/pip install pip-install-test
Collecting pip-install-test
  Using cached pip_install_test-0.5-py3-none-any.whl.metadata (979 bytes)
Using cached pip_install_test-0.5-py3-none-any.whl (1.7 kB)
Installing collected packages: pip-install-test
Successfully installed pip-install-test-0.5

[notice] A new release of pip is available: 24.3 -> 24.3.1
[notice] To update, run: python3 -m pip install --upgrade pip

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

The command isn't intended to be copy-pastable. There are too many edge cases (such as spaces or special characters in path names) which would require shell-specific quoting, and rather than have something that looks copy-pastable, but often isn't, we prefer to explain to the user what they need to do in more general terms.

[roubert]

The problem is that the current message looks copy-pasteable and in the vast majority of cases when copy-pasted it'll run and perform an update, just not updating the right thing.

I filed this after having had to help out explaining why the same message kept reappearing despite running the command.

[pfmoore]

If you have any suggestions for better wording, that would be fine. But something that can be copy-pasted is explicitly not a goal here. Consider if you had a virtual environment /home/André/my envs/env$1 - how would you make a message that was "directly copy-pastable"? Remember that you need to consider users of the CMD shell (where '...' quotes don't work) and Powershell (where any quoted path needs to be preceded by &) as well as any number of Unix shells.

[roubert]

I actually believe that such a command line, which resulted in an error message when copy-pasted if quoting was required, really would be a little bit more helpful than the current one which appears to work and update something, but updates the wrong thing.

[pfmoore]

We've had user reports saying the exact opposite in the past, unfortunately 🙁 This is one of those cases where you can't please everyone, no matter how hard you try, unfortunately.

[roubert]

Maybe one improvement could then be to make sure that the message doesn't include any command line that can be copy-pasted and executed directly, which would eliminate the problem of mistakenly updating the wrong thing.

[roubert]

I just came to realize one thing, this message already includes unquoted spaces (and also the full path into the venv), if the Python interpreter is invoked through some nonstandard name, so if I were to do a ln -s python3 'python 3' inside of my venv (and also give the venv a name with a space in it too, just for completeness), I'd get this:

$ 'te st/bin/python 3' -m pip install pip-install-test 
Collecting pip-install-test
  Using cached pip_install_test-0.5-py3-none-any.whl.metadata (979 bytes)
Using cached pip_install_test-0.5-py3-none-any.whl (1.7 kB)
Installing collected packages: pip-install-test
Successfully installed pip-install-test-0.5

[notice] A new release of pip is available: 24.3 -> 24.3.1
[notice] To update, run: /tmp/te st/bin/python 3 -m pip install --upgrade pip

So it seems that the risk of outputting an unquoted space hasn't been a concern for the current implementation and that a really straightforward improvement could be to treat an invocation from inside of a venv the same as using a nonstandard interpreter name.

[d97jro]

Second that.

[notatallshaw]

See related discussion: #12411, #12412, #10987, #10734

So it seems that the risk of outputting an unquoted space hasn't been a concern for the current implementation and that a really straightforward improvement could be to treat an invocation from inside of a venv the same as using a nonstandard interpreter name.

Can you give a concrete example of your suggestion, what it looks like now, what it would look like after.

I'm struggling to follow your reasoning here, as currently it is accepted to have an unquoted space because it is not a goal to copy and paste, but meant to be illustrative for the user. I'd need to see real examples to see if what you're suggesting improves the illustrativeness for users.