On 25 June 2016 at 15:40, Nathaniel Smith
On Sat, Jun 25, 2016 at 2:31 PM, Nick Coghlan
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@gmail.com | Brisbane, Australia