Hello List! I feel it’s fine to hold back the other changes for later but the upgrade-strategy change should get shipped out to the world as quickly as possible. Even how the change is exposed the user can also be discussed later.
I request the list members to focus on *only* the change of the default upgrade strategy to be non-eager. Does anyone have any concerns regarding the change of the default upgrade strategy to be non-eager? If not, let’s get *just* that shipped out as soon as possible. Cheers, Pradyun Gedam On Mon, 27 Jun 2016 at 12:02 Pradyun Gedam pradyu...@gmail.com <http://mailto:pradyu...@gmail.com> wrote: On Sun, 26 Jun 2016 at 23:02 Donald Stufft <don...@stufft.io> wrote: > >> >> On Jun 25, 2016, at 6:25 AM, Pradyun Gedam <pradyu...@gmail.com> wrote: >> >> There is currently a proposal to change the behaviour to pip install to >> upgrade a package that is passed even if it is already installed. >> >> This behaviour change is accompanied with a change in the upgrade >> strategy - pip would stop “eagerly” upgrading dependencies and would become >> more conservative, upgrading a dependency only when it doesn’t meet lower >> constraints of the newer version of a parent. Moreover, the behaviour of pip >> install --target would also be changed so that --upgrade no longer >> affects it. >> >> I think bundling these two changes (and I think I might have been the one >> that originally suggested it) is making this discussion harder than it >> needs to be as folks are having to fight on multiple different fronts at >> once. I think the change to the default behavior of pip install is >> dependent on the change to —upgrade, so I suggest we focus on the change to >> —upgrade first, changing from a “recursive” to a “conservative” strategy. >> Once we get that change figured out and landed then we can worry about what >> to do with pip install. >> > > You were. In fact, the majority swayed in favour of changing the behaviour > of pip install post one of your comments on Github. > > I'll be happier *only* seeing in change the behaviour of --upgrade and not > --target or pip install. It reduces the number of things that changes from > 3 to 1. Much easier to discuss about. > > I’m not going to repeat the entire post, but I just made a fairly lengthy >> comment at https://github.com/pypa/pip/issues/3786#issuecomment-228611906 but >> to try and boil it down to a few points: >> > > Thanks for this. > > >> * ``pip install —upgrade`` is not a good security mechanism, relying on >> it is inconsistent at best. If we want to support trying to keep people on >> secure versions of software we need a better mechanism than this anyways, >> so we shouldn’t let it influence our choice here. >> > > AFAIK, this was the only outstanding concern raised against having a > non-eager (conservative) upgrade strategy. > > * For the general case, it’s not going to matter a lot which way we go, >> but not upgrading has the greatest chance of not breaking *already >> installed software*. >> > > I strongly agree with this. Another thing worth a mention is that it's > easier to get the lower bounds of your requirements correct, rather than > upper bounds. > > >> * For the hard-to-upgrade case, the current behavior is so bad that >> people are outright attempting to subvert the way pip typically behaviors, >> *AND* advocating for other’s to do the same, in an attempt to escape that >> behavior. I think that this is not a good place to be in. >> > > Ditto. > > — >> >> Donald Stufft >> > > Happy-to-see-Donald's-response-ly, > Pradyun Gedam >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
