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

[Matthew Brett]

On Sun, Jun 26, 2016 at 11:59 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Sun, Jun 26, 2016 at 10:32 AM, 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.
>>
>> 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:
>>
>> * ``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.
>> * 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*.
>> * 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.
>
> I wonder whether it is worth going back to the proposal [1] to add
>
> pip upgrade
>
> To anyone who hasn't read [1], this would have the behavior proposed
> (always upgrades named packages, does not do recursive upgrade).
> Meanwhile `pip install` stays as is, but deprecates the `--upgrade`
> flag in favor of the new command.
>
> The cost of the new command, that duplicates some behavior of
> `install` - seems rather small - and we could always deprecate it
> later, once people had got used the new behavior.

And for the specific case of `pip install pkg` always upgrading, that
seems like a bad idea.

There are two sensible things that `pip install pkg` could do, one is
checking and not upgrading (current behavior), the other is upgrading
(proposed change).

I think it would piss a lot of people off if we change from one
sensible behavior to another without a significant degree of prior
warning.

Cheers,

Matthew