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

[Pradyun Gedam]

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.

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
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160627/4eb768f3/attachment-0001.html>