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

[Ralf Gommers]

On Mon, Jun 27, 2016 at 8:36 AM, 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.
>
What do you mean by "ship" if you say the behavior can still be changed
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.
>
The concerns were always with how to change it, one of:
(1) add "pip upgrade"
(2) change behavior of "pip install --upgrade"
(3) change behavior of "pip install"

Your sentence above suggests you're asking for agreement on (2), but I
think you want agreement on (3) right? At least that was the conclusion of
your PEP-style writeup.

Personally I don't have a preference anymore, as long as a choice is made
so we don't remain stuck where we are now.

Ralf




> Cheers,
> Pradyun Gedam
>
> On Mon, 27 Jun 2016 at 12:02 Pradyun Gedam pradyunsg at gmail.com
> <http://mailto:pradyunsg@gmail.com> wrote:
>
> On Sun, 26 Jun 2016 at 23:02 Donald Stufft <donald at stufft.io> wrote:
>>
>>>
>>> On Jun 25, 2016, at 6:25 AM, Pradyun Gedam <pradyunsg at gmail.com> wrote:
>>>
>>> There is currently a proposal to change the behaviour to pip install to
>>> upgrade a package that is passed even if it is already installed.
>>>
>>> This behaviour change is accompanied with a change in the upgrade
>>> strategy - pip would stop “eagerly” upgrading dependencies and would become
>>> more conservative, upgrading a dependency only when it doesn’t meet lower
>>> constraints of the newer version of a parent. Moreover, the behaviour of
>>>  pip install --target would also be changed so that --upgrade no longer
>>> affects it.
>>>
>>> I think bundling these two changes (and I think I might have been the
>>> one that originally suggested it) is making this discussion harder than it
>>> needs to be as folks are having to fight on multiple different fronts at
>>> once. I think the change to the default behavior of pip install is
>>> dependent on the change to —upgrade, so I suggest we focus on the change to
>>> —upgrade first, changing from a “recursive” to a “conservative” strategy.
>>> Once we get that change figured out and landed then we can worry about what
>>> to do with pip install.
>>>
>>
>> You were. In fact, the majority swayed in favour of changing the
>> behaviour of pip install post one of your comments on Github.
>>
>> I'll be happier *only* seeing in change the behaviour of --upgrade and
>> not --target or pip install. It reduces the number of things that changes
>> from 3 to 1. Much easier to discuss about.
>>
>> I’m not going to repeat the entire post, but I just made a fairly lengthy
>>> comment at
>>> https://github.com/pypa/pip/issues/3786#issuecomment-228611906 but to
>>> try and boil it down to a few points:
>>>
>>
>> Thanks for this.
>>
>>
>>> * ``pip install —upgrade`` is not a good security mechanism, relying on
>>> it is inconsistent at best. If we want to support trying to keep people on
>>> secure versions of software we need a better mechanism than this anyways,
>>> so we shouldn’t let it influence our choice here.
>>>
>>
>> AFAIK, this was the only outstanding concern raised against having a
>> non-eager (conservative) upgrade strategy.
>>
>> * For the general case, it’s not going to matter a lot which way we go,
>>> but not upgrading has the greatest chance of not breaking *already
>>> installed software*.
>>>
>>
>> I strongly agree with this. Another thing worth a mention is that it's
>> easier to get the lower bounds of your requirements correct, rather than
>> upper bounds.
>>
>>
>>> * For the hard-to-upgrade case, the current behavior is so bad that
>>> people are outright attempting to subvert the way pip typically behaviors,
>>> *AND* advocating for other’s to do the same, in an attempt to escape that
>>> behavior. I think that this is not a good place to be in.
>>>
>>
>> Ditto.
>>
>> —
>>>
>>> Donald Stufft
>>>
>>
>> Happy-to-see-Donald's-response-ly,
>> Pradyun Gedam
>>
> ​
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160627/09183b55/attachment-0001.html>