[Distutils] Request for comment: Proposal to change behaviour of pip install
ralf.gommers at gmail.com
Mon Jun 27 02:51:31 EDT 2016
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
What do you mean by "ship" if you say the behavior can still be changed
> 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.
> Pradyun Gedam
> On Mon, 27 Jun 2016 at 12:02 Pradyun Gedam pradyunsg at gmail.com
> <http://mailto:email@example.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.
>>> Donald Stufft
>> Pradyun Gedam
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG