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@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 <[email protected]> wrote: > > > On Jun 25, 2016, at 12:31 PM, Ian Cordasco <[email protected]> > wrote: > > > > On Sat, Jun 25, 2016 at 5:25 AM, Pradyun Gedam <[email protected]> > 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 - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
