Should note that the 'upgrade' behavior of apt-get install requires that you've also run `apt-get update` (I believe?) -- that seems like a pretty big difference since the user has control over when they update their upstream package lists.
A quick and dirty survey of other package manager behavior (very quick... may be wrong!): gem install is not idempotent, supports --conservative flag to alter. non-eager. npm install also not idempotent, and I don't see a flag to alter this. eager, but sub-dependencies are isolated per package -Dana On Sat, Jun 25, 2016 at 3:40 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Sat, Jun 25, 2016 at 2:31 PM, Nick Coghlan <ncogh...@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), > > Either way, having 'pip install' go ahead and do the upgrade gives the > user what they were expecting. > > It also reduces the state space: if 'pip install foo' has the > post-condition that it always leaves you with the latest version, then > that's much simpler to reason about then the version where it might > leave you with the latest version or it might not depending on what > other commands you might have run a year ago. And you don't have to > remember that if you really want to make sure you have the latest > version regardless of your starting state then that's 'pip install foo > || pip upgrade foo', or some other special incantation. And of course > if you write the wrong thing it will work fine on your machine, but > then when your users try following your tutorial then it goes wrong... > > Of course, there is a third mental state that the user might have been > in: that they didn't know whether 'foo' is installed, and they wanted > to guarantee that some version of 'foo' is installed, but they > genuinely didn't care what version that is, *and* they'd prefer to > keep an old version rather than upgrade. That's a fairly odd and > complicated mental state to be in, but I guess it does come up > sometimes (like in Ian's use case of writing automated sysadmin > scripts). I don't have any objection to making those semantics > *available*, but I think it's a bad idea to attach them to 'pip > install', since that's the obvious thing that new and non-expert users > will reach for, and new and non-expert users by definition do not have > that kind of complicated mental state. But it would make sense to me > to provide this functionality under an opt-in command specifically for > experts like 'pip require foo', or 'pip install --prefer-current foo'. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
