I find the whole discussion quite unnerving honestly. 

pip install should do just that. notifying me if I have a version and an upgrade is availalbe for *pip*, makes sense. doing anything *else* is scary. 

I expect --upgrade for upgrading things. THEN it should upgrade to the latest version, unless I use a flag to specify otherwise. 

Note -I'm talking from the "naive user" viewpoint. 

On Tue, Jun 28, 2016 at 5:03 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:


On Wed, Jun 29, 2016 at 12:45 AM, Robert Collins <robertc@robertcollins.net> wrote:
On 29 June 2016 at 10:38, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>
>
> On Wed, Jun 29, 2016 at 12:16 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>>
>> On 26 Jun 2016 23:37, "Pradyun Gedam" <pradyunsg@gmail.com> wrote:
>> >
>> > 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.
>>
>> Pairing that change with an explicit "pip upgrade-all" command would get a
>> +1 from me, especially if there was a printed warning when the new upgrade
>> strategy skips packages the old one would have updated.
>
> Please do not mix upgrade with upgrade-all. The latter is blocked by lack of
> a SAT solver for a long time, and at the current pace that status may not
> change for another couple of years. Also mixing these up is unnecessary, and
> it was discussed last year on this list already to move ahead with upgrade:
> http://article.gmane.org/gmane.comp.python.distutils.devel/24219

I realise the consensus on the ticket is that its blocked, but I don't
actually agree.

Yes, you can't do it *right* without a full resolver, but you can do
an approximation that would be a lot better than nothing (just narrow
the specifiers given across all requirements). That is actually
reasonable when you're dealing with a presumed-good-set of versions
(which install doesn't deal with).

Honestly, not sure how to respond. You may be right, I don't have a technical opinion on an approximate upgrade-all now. Don't really want to have one either - when N core PyPA devs have been in consensus for a couple of years, then when dev N+1 comes along at the very last moment to challenge that consensus plus make it blocking for something we agreed was unrelated, that just feels frustrating (especially because it's becoming a pattern).

Mixing separate discussions/implementations up together does seem to be a good way to make the whole thing stall again though, so I'll first try repeating "this is unnecessary, please do not mix upgrade and upgrade-all". Here's an alternative for the small minority that values the current upgrade behavior:
  1. add a --recursive flag to keep that behavior accessible.
  2. add the printed warning that Nick suggests above.
That way we can have better defaults soon (Pradyun's PR seems to be in decent shape), and add upgrade-all either when someone implements the full resolver or when there's agreement on your approximate version.

Ralf




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




--
cordially,
Anna