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

[Ralf Gommers]

@Pradyun thanks a lot for trying to get some movement in this issue again!


On Sun, Jun 26, 2016 at 8:27 AM, Pradyun Gedam <pradyunsg at gmail.com> wrote:

> I think it's useful to see what other tools and package managers do. Doing
> something like them because they do it is not a good reason. Doing it
> because it's better UX is a good reason.
>
> I like what git does, printing a (possibly long) message in a version
> cycle to warn users that the behavior would be changing in a future version
> and how they can/should act on it. It has a clean transition period that
> allows users to make educated decisions.
>
> I, personally, am more in the favor of providing a `--upgrade-strategy
> (eager/non-eager)` flag (currently defaulting to eager) with `--upgrade`
> with the the warning message printing as above followed by a switch to
> non-eager.
>
> These two combined is IMO the best way to do a transition to non-eager
> upgrades by default.
>
> That said, a change to non-eager upgrades be could potentially cause a
> security vulnerability because a security package is kept at an older
> version. This asks if we should default to non-eager upgrades. This
> definitely something that should be addressed first, before we even talk
> about the transition. I'm by no means in a position to make an proper
> response and decision on this but someone else on this thread probably is.
>

This was addressed, many times over. On the main issue [1], on the pypa-dev
mailing list [2], on this list [3]. The decision that this is going to
happen is even documented in the pip docs [4]. The PR was explicitly asked
for after all that discussion [5], and has been submitted last year already
with all concrete review comments addressed.

There's also a reason that issue [1] is one of the most "+1"-ed issues I've
come across on GitHub - the current upgrade behavior is absolutely horrible
(see [3] for why).



> On Sun, 26 Jun 2016 at 10:59 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 25 June 2016 at 21:59, Robert Collins <robertc at robertcollins.net>
>> wrote:
>> > Lastly, by defaulting to non-recursive upgrades we're putting the
>> > burden on our users to identify sensitive components and manage them
>> > much more carefully.
>>
>
That's why there's also a plan to add an update-all command (see [1]). And
there's still "update --recursive" as well.


> Huh, true. I was looking at this proposal from the point of view of
>> container build processes where the system packages are visible from
>> the venv, and there the "only install what I tell you, and only
>> upgrade what you absolutely have to" behaviour is useful (especially
>> since you're mainly doing it in the context of generating a new
>> requirements.txt that is used to to the *actual* build).
>>
>
That's not the main reason it's useful. Just wanting no unexpected upgrades
and no failing upgrades of working packages which contain compiled code
when you do a simple "pip install -U smallpurepythonpackage" are much more
important. See [3] for a more eloquent explanation.

Ralf


[1] https://github.com/pypa/pip/issues/59
[2]
https://groups.google.com/forum/#!searchin/pypa-dev/upgrade/pypa-dev/vVLmo1PevTg/oBkHCPBLb9YJ
[3] http://article.gmane.org/gmane.comp.python.distutils.devel/24218
[4]
https://pip.pypa.io/en/stable/user_guide/#only-if-needed-recursive-upgrade
[5] http://thread.gmane.org/gmane.comp.python.scientific.user/36377
[6] https://github.com/pypa/pip/pull/3194



> However, I now think Robert's right that that's the wrong way to look
>> at it - I am *not* a suitable audience for the defaults, since we can
>> adapt our automation pipeline to whatever combination of settings pip
>> tells us we need to get the behaviour we want (as long as we're given
>> suitable deprecation periods to adjust to any behavioural changes, and
>> we can largely control that ourselves by controlling when we upgrade
>> pip, including patching it if absolutely necessary).
>>
>> By contrast, for folks that *aren't* using something like VersionEye
>> or requires.io to stay on top of security updates, "always run the
>> latest version of everything, and try to keep up with that upgrade
>> treadmill" really is the safest way to go, and that's what the current
>> eager upgrade behaviour provides.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160626/5ae3c414/attachment-0001.html>