@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 <[email protected]> wrote: > 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 <[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. >> > 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/vVLmo1PevTg/oBkHCPBLb9YJ [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. >> >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
