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

Remove self_outdated_check? #8458

Open
oTree-org opened this issue Jun 17, 2020 · 14 comments
Open

Remove self_outdated_check? #8458

oTree-org opened this issue Jun 17, 2020 · 14 comments
Labels
state: needs discussion This needs some more discussion type: maintenance Related to Development and Maintenance Processes

Comments

@oTree-org
Copy link

oTree-org commented Jun 17, 2020

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:

#6443
#5346
#5420
#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.

image

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:

  • The users who are most affected by this are the newbies who do not know about this flag.
  • This is a small issue that affects a huge number of users. IMHO these settings & flags are good for the inverse situation (large annoyance that affects a small number of users). Even someone who dislikes the message will be unlikely to research whether it is possible to hide it. There is always something more urgent to work on. People live with it but I don't think that's ideal.
  • For people who work on many different servers, this configuration needs to be done multiple times.
@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Jun 17, 2020
@srinivasreddy
Copy link

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.

@pfmoore
Copy link
Member

pfmoore commented Jun 26, 2020

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.

@pradyunsg pradyunsg added state: needs discussion This needs some more discussion type: maintenance Related to Development and Maintenance Processes labels Jun 26, 2020
@triage-new-issues triage-new-issues bot removed the S: needs triage Issues/PRs that need to be triaged label Jun 26, 2020
@oTree-org
Copy link
Author

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?

@chrahunt
Copy link
Member

I think moving the warning to the top is a good idea.

@pradyunsg
Copy link
Member

We could also separate it visually, like how npm does it:

@ssbarnea
Copy link
Contributor

ssbarnea commented Dec 7, 2020

I have to say that this message did not help build a lot of love for pip itself. I found it bit invading, especially as it was too aggressive. While I can understand that using a 2 years old pip version does deserve a warning, I do not think that a two week one should. I would even suggest not checking for newer versions unless current one is not older than 30-60 days maybe? While I stopped using Windows more than decade ago, I do still find memes about Windows Update and Clippy ;)

Yep, I do find npm approach nicer, also use of colors is highly appreciated.

There is also another aspect that we may consider: how about displaying the warning only if pip exists without a success code. and even mentioning to try again with latest release? I can understand that we do not want more bugs about old versions and with a project that make often releases, is not hard for this to happen even with engineers that know the drill.

Maybe it is also the time to consider making pip bootstrapping itself like tox does. Tox is able to upgrade itself when needed without upgrading itself.

@zsimic
Copy link

zsimic commented Aug 3, 2021

+1, this warning is very annoying.

I try to use virtualenv --download (hoping to avoid this warning), yet I still see this warning all the time...

The only way to avoid this warning (that I could find) is to systematically run .../bin/pip install -U pip after every single venv creation (which can be hard to do, when other tools create venvs, for example tox...)... and even so, you still get to see the warning at least once...

@hugovk
Copy link
Contributor

hugovk commented Aug 4, 2021

@zsimic This check can be disabled via the --disable-pip-version-check or setting disable_pip_version_check = 1 in pip.conf (https://pip.pypa.io/en/latest/topics/configuration/).

@pfmoore
Copy link
Member

pfmoore commented Aug 4, 2021

To be clear, we probably could improve the way the warning is displayed (there are suggestions in this thread already). However, as @hugovk notes, it is possible to disable it now, so improvements are not a high priority (and no-one appears sufficiently motivated to create a PR, again suggesting this isn't a major pain point for people).

The fact that new virtual environments are created with older pip versions is a specific design trade-off in virtualenv, trying to ensure that environment creation is fast by using a local copy of pip (which gets updated on a regular basis, but not immediately a pip release happens). Whether that trade-off has worked as well as people would like is a question for the virtualenv project, not for pip.

@pradyunsg
Copy link
Member

I try to use virtualenv --download (hoping to avoid this warning), yet I still see this warning all the time...

Assuming you're on a recent virtualenv release, an easier approach would be to run virtualenv --upgrade-embed-wheels periodically (basically after a pip release). That'll mean all your environment would be created with a recent pip release.

@zsimic
Copy link

zsimic commented Aug 5, 2021

virtualenv --upgrade-embed-wheels shows a lot of SSL complaints, but it seems to trigger an update. However, I may as well then rm -rf ~/Library/Application\ Support/virtualenv/ -> same outcome... (without further weird warnings, and ends up working faster too)

My virtualenv is always at latest version :)

I'll see if I can carve some time to do a PR, see if I can make this a bit better.

@zsimic
Copy link

zsimic commented Aug 5, 2021

I'm hesitating to add yet another thing like --disable-pip-version-check... ideally, pip would do its thing without warnings (and there would be a nice/easy way to ensure latest version is used, since that's what's recommended).

I'm thinking ideally pip itself would just self-upgrade by default (and stop complaining about latest version), with an opt-out in pip.conf for whoever doesn't want that.

As a user, I'd love to let pip do its thing, as recommended by pip authors. If pip should always be at latest version, so be it -> I'm OK with that. I just don't want to see warnings :) (as they pollute logs... and if you have 100s of CI jobs, they all get that warnings pollution N times over, each).

So, I'm thinking, if "use latest pip" is the recommended thing, then it should be the default (enforced by pip itself), with an opt-out possibly for whoever wants to not adhere to that.

@oTree-org
Copy link
Author

FYI I opened this PR a while back: #9111
I guess there was some small unresolved thing like a linting error.

@pfmoore
Copy link
Member

pfmoore commented Aug 5, 2021

-1 on update by default. That would probably result in even more complaints from users than the current warning...

@oTree-org I closed and re-opened your PR to re-trigger the CI. It looks like there's at least a trailing whitespace issue to fix. If you want to continue working on that PR, I suggest you fix the issues and rebase on the latest main, and then it can be reviewed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: needs discussion This needs some more discussion type: maintenance Related to Development and Maintenance Processes
Projects
None yet
Development

No branches or pull requests

8 participants