On Wed, Jun 29, 2016 at 7:46 AM, Nick Coghlan <[email protected]> wrote:
> > 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). > Interesting. Issue https://github.com/pypa/pip/issues/59 is now dedicated to upgrade-all (https://github.com/pypa/pip/issues/3786 is for upgrade), so I'll copy the comments of Robert and you there. > 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. > Thank you Nick. Ralf
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
