Hello List!

I feel it’s fine to hold back the other changes for later but the
upgrade-strategy change should get shipped out to the world as quickly as
possible. Even how the change is exposed the user can also be discussed later.

I request the list members to focus on only the change of the default
upgrade strategy to be non-eager.

Does anyone have any concerns regarding the change of the default upgrade
strategy to be non-eager? If not, let’s get just that shipped out as soon as possible.

Cheers,
Pradyun Gedam

On Mon, 27 Jun 2016 at 12:02 Pradyun Gedam pradyunsg@gmail.com wrote:

On Sun, 26 Jun 2016 at 23:02 Donald Stufft <donald@stufft.io> wrote:

On Jun 25, 2016, at 6:25 AM, Pradyun Gedam <pradyunsg@gmail.com> wrote:

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.

I think bundling these two changes (and I think I might have been the one that originally suggested it) is making this discussion harder than it needs to be as folks are having to fight on multiple different fronts at once. I think the change to the default behavior of pip install is dependent on the change to —upgrade, so I suggest we focus on the change to —upgrade first, changing from a “recursive” to a “conservative” strategy. Once we get that change figured out and landed then we can worry about what to do with pip install.

You were. In fact, the majority swayed in favour of changing the behaviour of pip install post one of your comments on Github.

I'll be happier *only* seeing in change the behaviour of --upgrade and not --target or pip install. It reduces the number of things that changes from 3 to 1. Much easier to discuss about.

I’m not going to repeat the entire post, but I just made a fairly lengthy comment at https://github.com/pypa/pip/issues/3786#issuecomment-228611906 but to try and boil it down to a few points:

Thanks for this.
 

* ``pip install —upgrade`` is not a good security mechanism, relying on it is inconsistent at best. If we want to support trying to keep people on secure versions of software we need a better mechanism than this anyways, so we shouldn’t let it influence our choice here.

AFAIK, this was the only outstanding concern raised against having a non-eager (conservative) upgrade strategy.

* For the general case, it’s not going to matter a lot which way we go, but not upgrading has the greatest chance of not breaking *already installed software*.

I strongly agree with this. Another thing worth a mention is that it's easier to get the lower bounds of your requirements correct, rather than upper bounds.

 

* For the hard-to-upgrade case, the current behavior is so bad that people are outright attempting to subvert the way pip typically behaviors, *AND* advocating for other’s to do the same, in an attempt to escape that behavior. I think that this is not a good place to be in.

Ditto.

—

Donald Stufft

Happy-to-see-Donald's-response-ly,

Pradyun Gedam

​

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