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 <[email protected]> wrote: > On 25 June 2016 at 21:59, Robert Collins <[email protected]> > 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 | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
