On 25 June 2016 at 21:59, Robert Collins
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