I find the whole discussion quite unnerving honestly. pip install should do just that. notifying me if I have a version and an upgrade is availalbe for *pip*, makes sense. doing anything *else* is scary.
I expect --upgrade for upgrading things. THEN it should upgrade to the latest version, unless I use a flag to specify otherwise. Note -I'm talking from the "naive user" viewpoint. On Tue, Jun 28, 2016 at 5:03 PM, Ralf Gommers <[email protected]> wrote: > > > On Wed, Jun 29, 2016 at 12:45 AM, Robert Collins < > [email protected]> wrote: > >> On 29 June 2016 at 10:38, Ralf Gommers <[email protected]> wrote: >> > >> > >> > On Wed, Jun 29, 2016 at 12:16 AM, Nick Coghlan <[email protected]> >> wrote: >> >> >> >> >> >> On 26 Jun 2016 23:37, "Pradyun Gedam" <[email protected]> wrote: >> >> > >> >> > 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. >> >> >> >> Pairing that change with an explicit "pip upgrade-all" command would >> get a >> >> +1 from me, especially if there was a printed warning when the new >> upgrade >> >> strategy skips packages the old one would have updated. >> > >> > Please do not mix upgrade with upgrade-all. The latter is blocked by >> lack of >> > a SAT solver for a long time, and at the current pace that status may >> not >> > change for another couple of years. Also mixing these up is >> unnecessary, and >> > it was discussed last year on this list already to move ahead with >> upgrade: >> > http://article.gmane.org/gmane.comp.python.distutils.devel/24219 >> >> I realise the consensus on the ticket is that its blocked, but I don't >> actually agree. >> >> Yes, you can't do it *right* without a full resolver, but you can do >> an approximation that would be a lot better than nothing (just narrow >> the specifiers given across all requirements). That is actually >> reasonable when you're dealing with a presumed-good-set of versions >> (which install doesn't deal with). >> > > Honestly, not sure how to respond. You may be right, I don't have a > technical opinion on an approximate upgrade-all now. Don't really want to > have one either - when N core PyPA devs have been in consensus for a couple > of years, then when dev N+1 comes along at the very last moment to > challenge that consensus plus make it blocking for something we agreed was > unrelated, that just feels frustrating (especially because it's becoming a > pattern). > > Mixing separate discussions/implementations up together does seem to be a > good way to make the whole thing stall again though, so I'll first try > repeating "this is unnecessary, please do not mix upgrade and upgrade-all". > Here's an alternative for the small minority that values the current > upgrade behavior: > 1. add a --recursive flag to keep that behavior accessible. > 2. add the printed warning that Nick suggests above. > That way we can have better defaults soon (Pradyun's PR seems to be in > decent shape), and add upgrade-all either when someone implements the full > resolver or when there's agreement on your approximate version. > > Ralf > > > > > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig > > -- cordially, Anna
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
