Once a day check PyPI for the latest version of pip

[dstufft]

Packaging is quickly evolving and it's recommended that users upgrade as quick as possible. This will let users know that there is an upgrade available in a non intrusive method. In case that someone does not wish to ping PyPI once a day or so (assuming they are executing pip at least once a day) there is an option to disable it --disable-version-check.

[qwcode]

ok, but let's add tests for this..

[dstufft]

ok!

[qwcode]

after having fixed a series of 1-2 yr old bugs recently, that never had to exist, if tests had been added originally, I'm a little sensitive : )

[dstufft]

No worries! I like having someone keep me honest :)

[dstufft]

It's why I typically like either someone else to merge my PRs, or someone to tell me to merge them :)

[hpk42]

I don't like that pip suddenly hardcodes a connection to https://pypi.python.org here. When using devpi-server, it serves as the sole endpoint for pip but this change would break that.

Independently, there might be reasons why systems use a specific pip version. I understand it's possible to disable the version check but i remeain skeptical of the whole idea. People usually have a lot of software and it's more useful to use some of the pip wrappers/helps which check about e.g. all versions in a virtualenv or requirements.txt. pip doing this self-check isn't not really buying that much i would think.

[dstufft]

The typical index server isn't used because it's not using PackageFinder so it doesn't use the simple API and because it's explicitly asking if the pip developers have released a newer version or not, not if a newer version is installable.

If a system uses a specific version they are free too. They can either just visually ignore the message (It's just a warning, it's not a prompt or anything) or they can disable the check.

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've talked to a few people involved in projects that used similar checks during periods of rapid improvement and their views have all been positive towards it.

Personally I believe that the check does buy a good bit, and the downsides are pretty minimal.

[hpk42]

If i see it correctly, the PR currently raises if a connection to https://pypi.python.org cannot be established or errors out. This would break in confined environments (where people might choose to install only from local sources, or via devpi-server which allows temporary offline operations). So at least the check should never error out or disrupt installations.

Moreover, devpi-server can easily offer the "json" page but the question is how the check could be extended to try it.

Also, i think this change means that all tox runs will do the version check for each environment ... or wait. How is this going to work at all? If pip stores the versioncheck timestamp in the home dir, what about different virtualenvs using different versions of pip? Would this check even reliably work?

[dstufft]

This PR swallows any exceptions that happens inside the version checking and simply logs an error (to a level that is not displayed by default).

Yes it's true it stores it in the home directory and that a check on one virtualenv may prevent a check on another virtualenv. I decided to keep it this way to prevent users from getting "warning fatigue".

[alex]

You don't need a str here. Also, you might want to consider a way to dump the traceback, sooner or later you'll want it.

[dstufft]

I've addressed most of the concerns @alex had besides how virtual environments are going to be handled.

@hpk42 I would expect a tool like tox to issue --disable-version-check because you don't show the output of the pip install command anyways.

So I guess we need to figure out what solution we find acceptable for this. The largest worry is that of warning fatigue. I think it's somewhat unnice to spam the user with a bunch of warnings if they are purposely ignoring the upgrade instructions (although perhaps the answer is --disable-version-check in that case?).

[dstufft]

Oh also @hpk42 does the fact that this swallows exceptions and provides a way to disable it satisfy your concerns with it? It will use the same requests settings as the rest of pip so things like proxies and such will automatically be carried over.

[hpk42]

tox already has a problem in that it needs to adapt to pip-1.3.1/pip-1.4 changes (--pre). With this PR accepted it might need to grow support for passing --disable-version-checks as well. Obviously, from that perspective i generally prefer it if behaviour changes are triggered by an option, rather than the need to neutralize a change via a new option. Doesn't really work here because you want to force the check. I assume it's possible to set an environment variable as well to disable the check. Is that right?

[dstufft]

Yea, all pip options should be settable by flag, env var, or config file. It's baked into the configuration system as far as I know.

[qwcode]

yes, PIP_* is baked into the config system for any flag/option, and a lot of that code got new tests recently!!

[dstufft]

Still need to write tests for this, but I've refactored this so it only hits PyPI once a week. It stores the last check and the version it found and uses that for comparison.

[dstufft]

I'm withdrawing this PR.