Am 26.03.2015 um 04:09 schröbte Hisham: > > [...] > > We have some design options, see below: (commands that don't hit the > network are marked "[no network op]") > > Option a: add an 'upgrade' command. (Cue people asking for `upgrade > --all` in 3...2...1...) > > $ luarocks show foo --mversion > 1.0-1 [no network op] > $ luarocks install foo > Rock 'foo' is already installed. [no network op] > $ luarocks upgrade foo > <checks latest version in the network...> > <Installing foo 2.0...> > $ luarocks upgrade foo > <checks latest version in the network...> > Rock 'foo' version 2.0-1 is already installed. > $ luarocks install foo 2.0 > Rock 'foo' is already at version 2.0-1. [no network op] > $ luarocks install foo 2.0 --force > <installing foo 2.0 on top of same version...>
What would `luarocks upgrade foo` do if the package foo is not installed yet? Raise an error? That doesn't seem particular useful. If it just installs the package, then `upgrade` and `install` are almost identical (and I'd probably use `upgrade` exclusively), and the `upgrade` functionality would be better off as a flag to `install` (see option b). Also `luarocks install foo` (currently, or when `foo` is not yet installed) always installs the latest and greatest version with all bugfixes, and that's what I want when I don't specify a version (personal preference, I know). Changing that behavior when `foo` is already installed seems inconsistent to me. Regarding network access: In the most common case `luarocks install` already accesses the network, and when I say `luarocks install foo`, I have to expect that a network transfer is involved, so I see no particular benefit in guaranteeing network-less operation for this command in some cases. > > Option b: same as above, but with '--upgrade' flag instead of new command. > > $ luarocks show foo --mversion > 1.0-1 [no network op] > $ luarocks install foo > Rock 'foo' is already installed. [no network op] > $ luarocks install foo --upgrade > <checks latest version in the network...> > <Installing foo 2.0...> > $ luarocks install foo --upgrade > <checks latest version in the network...> > Rock 'foo' version 2.0-1 is already installed. > $ luarocks install foo 2.0 > Rock 'foo' is already at version 2.0-1. [no network op] > $ luarocks install foo 2.0 --force > <installing foo 2.0 on top of same version...> In my opinion the `--upgrade` case should be the default. `luarocks install foo` should *always* make sure that the latest version of `foo` is installed afterwards. Maybe a `--no-upgrade` flag? Which brings us to C: > > Option c: try to upgrade by default (plain `install` does what > `install --upgrade` in Option b does). Simpler, but now there's no way > to "install only if not present" without hitting the network. > > $ luarocks show foo --mversion > 1.0-1 [no network op] > $ luarocks install foo > <checks latest version in the network...> > <Installing foo 2.0...> > $ luarocks install foo > <checks latest version in the network...> > Rock 'foo' version 2.0.-1 is already installed. > $ luarocks install foo 2.0 > Rock 'foo' is already at version 2.0-1. [no network op] > $ luarocks install foo 2.0 --force > <installing foo 2.0 on top of same version...> This is my preferred option. The end result of `luarocks install foo` is always the same. Also the most common cases (IMHO) don't need extra command line flags. I have already covered the network access issue above. > > Option d: variant of the above, but imply "force" when given a version. > > $ luarocks show foo --mversion > 1.0-1 [no network op] > $ luarocks install foo > <checks latest version in the network...> > <Installing foo 2.0...> > $ luarocks install foo > <checks latest version in the network...> > Rock 'foo' version 2.0.-1 is already installed. > $ luarocks install foo 2.0 > <installing foo 2.0 on top of same version...> I don't like implying flags in non-obvious situations, especially for potentially destructive flags like `--force` (although it's not as bad as it sounds in this situation). > > -- Hisham > Philipp ------------------------------------------------------------------------------ _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
