On 25 June 2016 at 15:40, Nathaniel Smith <[email protected]> wrote: > On Sat, Jun 25, 2016 at 2:31 PM, Nick Coghlan <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
