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

Nick Coghlan ncoghlan at gmail.com
Sun Jun 26 00:44:44 EDT 2016


On 25 June 2016 at 15:40, Nathaniel Smith <njs at pobox.com> wrote:
> On Sat, Jun 25, 2016 at 2:31 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Thanks for putting that together. The assertion in the write-up that
>> the proposed behaviour matches that of operating system level package
>> managers doesn't sound right to me:
>>
>> $ sudo dnf install -q python
>> Package python-2.7.11-5.fc24.x86_64 is already installed, skipping.
>>
>> (My system actually has a Python update pending, so the "-q" option is
>> suppressing the output telling me about that, but either way, it
>> doesn't make any local changes unless I use the update or upgrade
>> subcommand or supply the "--best" upgrade strategy option to the
>> install command)
>
> Right -- this is partly my error, because I missed this earlier in the
> discussion (didn't yum use to at least offer an interactive prompt to
> upgrade or something instead? I guess it doesn't matter).
>
>> As far as I am aware, apt-get install behaves the same way - if you
>> only give a package name, and that package is already installed on the
>> system, it won't do anything, even if a newer version of that
>> component is available, and you need to use the "upgrade" subcommand
>> instead to say "upgrade to the latest available version".
>
> No, FWIW, apt-get acts like the proposed pip install. From the apt-get
> man page (my emphasis):
>
>        install
>            install is followed by one or more packages desired for
>            installation *or upgrading*
>            [...]
>            This is also the target to use if you want to upgrade one or more
>            already-installed packages without upgrading every package you have
>            on your system. Unlike the "upgrade" target, which installs the
>            newest version of all currently installed packages, "install" will
>            install the newest version of only the package(s) specified. Simply
>            provide the name of the package(s) you wish to upgrade, and if a
>            newer version is available, it (and its dependencies, as described
>            above) will be downloaded and installed.
>
> Personally I think this is better UX than the dnf approach. Let's take
> a Bayesian approach :-). What people really want is software that
> reads their mind and does what they mean. We can't read the user's
> mind, but if they type 'pip install foo' and 'foo' is already
> installed, then their mental state must have somehow prompted them to
> think that this was a good thing to do, so we can make some inferences
> about what they must be thinking. I think there are two main mental
> states that might have led them to type this strange thing:
>
> - they didn't know 'foo' was installed, so they expected 'pip install
> foo' to install it from scratch, and leave them with the latest
> version.
>
> - they knew 'foo' was installed, and they (mistakenly or not) believed
> that 'pip install' acts like 'apt-get install' and this is the way to
> upgrade to the latest version. (Maybe they believe this because they
> are Ubuntu users, maybe because 'pip install' is the only command they
> know and they are making a guess, whatever),

No, it's an idempotent assertion about the system state: "Make sure X
is available, installing it if necessary".

Maybe Debian folks are used to system packages stripping out the pip
metadata, so pip has no idea what's installed, even if the system
site-packages is configured to be visible in the venv?

Python is not Linux, and it definitely isn't just Debian, so "apt does
it that way" is not a good argument for changing behaviout that isn't
broken.

Changing "--upgrade" to the non-eager update strategy for dependencies
makes perfect sense, I just want "pip install" without the --upgrade
flag to continue to be treated the same way that dependency updates
are going to be treated in the "--upgrade" case.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Distutils-SIG mailing list