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

[Ian Cordasco]

On Sat, Jun 25, 2016 at 5:25 AM, Pradyun Gedam <pradyunsg at 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.

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.