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

[Daniel Holth]

Are you suggesting that my current vagrant provisioning script "ensure x is
installed":

ensure_x.sh:
#!/bin/sh
pip install x

Which IIUC does not currently check the network if x is already installed,
is no longer idempotent, and will permanently brick my development
environment as soon as x is upgraded on pypi? Do I have to include logic
for checking the current version of pip, and then decide how to upgrade? Do
I just pin all dependencies always?

I just spent 3 weeks fixing a nodejs deployment that had been upgraded when
I was not ready, and I would rather not have to do the same in pip.

Why don't we just implement something like pip install foobar at latest if you
want the upgrade?

pip upsert?

The idea of always upgrading when you specify a concrete dependency, a file
or a URL, is a good one.

On Sat, Jun 25, 2016 at 1:17 PM Donald Stufft <donald at stufft.io> wrote:

>
> > On Jun 25, 2016, at 12:31 PM, Ian Cordasco <graffatcolmingov at gmail.com>
> wrote:
> >
> > 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.
>
> 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160625/5e494530/attachment-0001.html>