> On Jun 25, 2016, at 12:31 PM, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
>
> On Sat, Jun 25, 2016 at 5:25 AM, Pradyun Gedam <pradyunsg@gmail.com> wrote:
>> Hello List!
>>
>> 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.
>>
>> A PEP-style write-up
>> (https://gist.github.com/pradyunsg/4c9db6a212239fee69b429c96cdc3d73)
>> documents the reasoning behind this proposed change, what the change is and
>> some alternate proposals that were rejected in the discussions.
>>
>> This is a request for comments on the pull-request implementing this
>> proposal (https://github.com/pypa/pip/pull/3806) for your views, thoughts
>> and possible concerns related to it.
>
> Having `pip install` implicitly upgrade a package will break the way
> tooling like ansible, puppet, salt, and chef all work. Most expect
> that if you do `pip install requests` twice you won't get two
> different versions. At the very least, there should be an option added
> that implies that if the version of the specified package is already
> installed and satisfactory, that it is not upgraded.

So this may be true, but it’s also not particularly hard to work around
similarly to what they do already for system package managers, they can
do ``pip list`` or ``pip freeze`` to see if something is already installed.
Not only will this work across versions, but it’ll also work *better*
because it won’t involve hitting the network to determine this information.

>
> That said, this will also break those tools understanding of how `pip
> install --upgrade` works if instead `-U/--upgrade` is kept. People who
> are automating deployments  using pip (perhaps in virtualenvs or
> however else, it really doesn't matter) will now be forced to
> periodically increase their lower bounds or list out *every*
> dependency to ensure they upgrade if that's what they want rather than
> being able to rely on pip to do that. They'll now have to specify
> their requirements list in more than one place, and this will not be
> something that's an improvement to the tooling in the community. Will
> it make some things more explicit? Maybe. Will it cause people trying
> to deploy software to waste hours of their time? Definitely.
>
> If you want to change the upgrade behaviour of pip, I suggest not
> modifying the existing `pip install` and instead deprecating that in
> favor of a new command. Silently pulling the rug out from under people
> seems like an incredibly bad idea.
>

This is going to break things, no matter what we do— and the current
behavior is also broken in ways that are causing other projects to need
to do broken things.

The current solution I think breaks *less* things and once the initial
pain of breakage is over will end up with a much nicer situation. Importantly
the vast bulk of the breakage will be centralized in things like Chef where
one group can make a change and fix it for thousands.

—
Donald Stufft



_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig