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

[Ralf Gommers]

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).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160629/124586f6/attachment.html>