@Pradyun thanks a lot for trying to get some movement in this issue again!
On Sun, Jun 26, 2016 at 8:27 AM, Pradyun Gedam
I think it's useful to see what other tools and package managers do. Doing something like them because they do it is not a good reason. Doing it because it's better UX is a good reason.
I like what git does, printing a (possibly long) message in a version cycle to warn users that the behavior would be changing in a future version and how they can/should act on it. It has a clean transition period that allows users to make educated decisions.
I, personally, am more in the favor of providing a `--upgrade-strategy (eager/non-eager)` flag (currently defaulting to eager) with `--upgrade` with the the warning message printing as above followed by a switch to non-eager.
These two combined is IMO the best way to do a transition to non-eager upgrades by default.
That said, a change to non-eager upgrades be could potentially cause a security vulnerability because a security package is kept at an older version. This asks if we should default to non-eager upgrades. This definitely something that should be addressed first, before we even talk about the transition. I'm by no means in a position to make an proper response and decision on this but someone else on this thread probably is.
This was addressed, many times over. On the main issue [1], on the pypa-dev mailing list [2], on this list [3]. The decision that this is going to happen is even documented in the pip docs [4]. The PR was explicitly asked for after all that discussion [5], and has been submitted last year already with all concrete review comments addressed. There's also a reason that issue [1] is one of the most "+1"-ed issues I've come across on GitHub - the current upgrade behavior is absolutely horrible (see [3] for why).
On Sun, 26 Jun 2016 at 10:59 Nick Coghlan
wrote: On 25 June 2016 at 21:59, Robert Collins
wrote: Lastly, by defaulting to non-recursive upgrades we're putting the burden on our users to identify sensitive components and manage them much more carefully.
That's why there's also a plan to add an update-all command (see [1]). And there's still "update --recursive" as well.
Huh, true. I was looking at this proposal from the point of view of
container build processes where the system packages are visible from the venv, and there the "only install what I tell you, and only upgrade what you absolutely have to" behaviour is useful (especially since you're mainly doing it in the context of generating a new requirements.txt that is used to to the *actual* build).
That's not the main reason it's useful. Just wanting no unexpected upgrades and no failing upgrades of working packages which contain compiled code when you do a simple "pip install -U smallpurepythonpackage" are much more important. See [3] for a more eloquent explanation. Ralf [1] https://github.com/pypa/pip/issues/59 [2] https://groups.google.com/forum/#!searchin/pypa-dev/upgrade/pypa-dev/vVLmo1P... [3] http://article.gmane.org/gmane.comp.python.distutils.devel/24218 [4] https://pip.pypa.io/en/stable/user_guide/#only-if-needed-recursive-upgrade [5] http://thread.gmane.org/gmane.comp.python.scientific.user/36377 [6] https://github.com/pypa/pip/pull/3194
However, I now think Robert's right that that's the wrong way to look
at it - I am *not* a suitable audience for the defaults, since we can adapt our automation pipeline to whatever combination of settings pip tells us we need to get the behaviour we want (as long as we're given suitable deprecation periods to adjust to any behavioural changes, and we can largely control that ourselves by controlling when we upgrade pip, including patching it if absolutely necessary).
By contrast, for folks that *aren't* using something like VersionEye or requires.io to stay on top of security updates, "always run the latest version of everything, and try to keep up with that upgrade treadmill" really is the safest way to go, and that's what the current eager upgrade behaviour provides.