[Distutils] Request for comment: Proposal to change behaviour of pip install

[Nick Coghlan]

On 28 Jun 2016 5:04 pm, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
>
>
> On Wed, Jun 29, 2016 at 12:45 AM, Robert Collins <
robertc at robertcollins.net> wrote:
>>
>> On 29 June 2016 at 10:38, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> >
>> >
>> > On Wed, Jun 29, 2016 at 12:16 AM, Nick Coghlan <ncoghlan at gmail.com>
wrote:
>> >>
>> >>
>> >> On 26 Jun 2016 23:37, "Pradyun Gedam" <pradyunsg at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160628/3cb2d55f/attachment-0001.html>