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

[Ralf Gommers]

On Wed, Jun 29, 2016 at 7:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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