On 28 Jun 2016 5:04 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).
"yum upgrade" has worked well enough for years without a proper SAT solver, and the package set in a typical Linux install is much larger than that in a typical virtual environment (although distro curation does reduce the likelihood of conflicting requirements arising in the first place). That said, rerunning pip-compile and then doing a pip-sync is already a functional equivalent of an upgrade-all operation (as is destroying and recreating a venv), so I agree there's no need to couple the question of supporting bulk upgrades in baseline pip with changing the behaviour of upgrading named components. Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
