This issue relates to the following warning:
WARNING: You are using pip version 20.1; however, version 20.1.1 is available.
You should consider upgrading via the 'c:\tracking\ve-track\scripts\python.exe -m pip install --upgrade pip' command.
I read the original rationale for this feature from 2013:
"The purpose of this message is simple, the more people on newer versions of pip the better while the world of packaging is improving as rapidly as it is. Ideally the goal would be to remove this check once things have settled down a bit."
I am wondering if now may be a good time to consider that.
Firstly, this code could be deleted:
https://github.com/pypa/pip/blob/master/src/pip/_internal/self_outdated_check.py
https://github.com/pypa/pip/blob/master/tests/unit/test_self_check_outdated.py
And a number of issues would be go away, for example see:
https://github.com/pypa/pip/issues/6443
https://github.com/pypa/pip/issues/5346
https://github.com/pypa/pip/issues/5420
https://github.com/pypa/pip/issues/6468
But more important is the user experience. This warning is shown to a huge number of people, and can be one of the first things they see when they get started with Python (e.g. if they are learning Python to use a specific package).
Confusion
I frequently see users thinking this is an error. For example: https://youtu.be/k8NXfeItBdw?t=295
For a new user who is already overwhelmed by getting started with Python, you may be surprised how much they can get sidetracked by this warning. Furthermore, many people don't know how to copy/paste from their terminal window, so they type character by character. When the provided command is something like
'c:\tracking\ve-track\scripts\python.exe -m pip install --upgrade pip'
They will likely get a typo, meaning they retype everything char by char.
This warning also obscures & distracts from actual errors. Here is a screenshot I got from a user who could not figure out why her installation was not working.
I don't blame them because for me the pip warning is the first thing my eye gets drawn to, especially because the wording is very direct ("you are", "you should"). I have also seen users who think that command will upgrade Python or all their pip-installed packages.
I know pip issues happen but is it often enough that all Python users need to be exposed to the warning by default, even if the pip command succeeded? There is a cost in distractions and "warning fatigue".
First impression of Python
For someone who is intimidated by beginning programming, dealing with messages like these can be discouraging. To build up people's confidence, it would be nice if the first impression of Python is that everything "just works".
It may also seem lame to a user that as soon as they install Python, they are immediately told to upgrade.
Note about disable_pip_version_check
Although this check can be disabled via the --disable-pip-version-check and setting disable_pip_version_check = 1 in pip.conf, I don't think that is an effective solution, because:
How about adding to the message that this is perfectly fine, and he could ignore the message and proceed to do whatever he wants to do? Some thing like this.
WARNING: You are using pip version 20.1; however, version 20.1.1 is available.
You are perfectly fine to ignore this warning, or you may consider upgrading via the 'c:\tracking\ve-track\scripts\python.exe -m pip install --upgrade pip' command.
The problem is that it's not "perfectly fine" to ignore this. We're still very actively working on modernising a lot of pip's packaging standards, and if people don't upgrade, then it becomes much harder to progress with those standards.
Standards like pyproject.toml
will never get adopted by popular packages if we can't be sure that people are using modern packaging tools that support that format. It's hard enough to argue that a popular project like requests should change their build process (which is not their core concern) if doing so would lose them users and offer them little benefit as they don't need the extra features of the new format. And if popular packages never adopt the new standards, pip can never drop support for older approaches, and we're unable to improve the ecosystem as a whole.
Maybe nagging people to upgrade isn't the best approach, but it's not obvious what would work better.
Thank you @pfmoore for the response. How about showing the warning at the beginning of the output, rather than the end? That way it will still be prominent, but does not obscure the result of the user's command. For example:
(ve-track) C:\site [master]> pip3 install -U requests
WARNING: You are using pip version 20.1; however, version 20.1.1 is available.
You should consider upgrading via the 'c:\tracking\ve-track\scripts\python.exe -m pip install --upgrade pip' command.
Collecting requests
[...]
Successfully installed requests-2.24.0
This seems more conventional to me, and in fact the top is where pip displays its other warnings, such as "pip 21.0 will drop support for Python 2.7 in January 2021..." and "The directory '%s' or its parent directory is not owned or is not writable by the current user...".
For comparison this is how Heroku suggests updates also:
(ve-track) C:\site [master]> heroku config:set PRODUCTION=1
» Warning: heroku update available from 7.42.1 to 7.42.2.
Setting PRODUCTION and restarting ⬢ my-backend... done, v23
PRODUCTION: 1
It looks like this can be done by moving the line self.handle_pip_version_check(options)
from the bottom of base_command.Command._main
to closer up top, where the other warnings are shown.
What do you think?
I think moving the warning to the top is a good idea.
We could also separate it visually, like how npm does it:
Most helpful comment
The problem is that it's not "perfectly fine" to ignore this. We're still very actively working on modernising a lot of pip's packaging standards, and if people don't upgrade, then it becomes much harder to progress with those standards.
Standards like
pyproject.toml
will never get adopted by popular packages if we can't be sure that people are using modern packaging tools that support that format. It's hard enough to argue that a popular project like requests should change their build process (which is not their core concern) if doing so would lose them users and offer them little benefit as they don't need the extra features of the new format. And if popular packages never adopt the new standards, pip can never drop support for older approaches, and we're unable to improve the ecosystem as a whole.Maybe nagging people to upgrade isn't the best approach, but it's not obvious what would work better.