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.

On Sun, 26 Jun 2016 at 10:59 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 25 June 2016 at 21:59, Robert Collins <robertc@robertcollins.net> 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.

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).

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.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig