Alex Kost <alez...@gmail.com> skribis: > Ludovic Courtès (2016-04-18 20:20 +0300) wrote:
[...] >> I can see how adding “package” everywhere helps categorize things >> mentally, but as a user interface, I think it would be rather bad. > > As a user, I think it would be rather good. (This is just my user opinion) To clarify, what I meant is that forcing users to type an additional word for common operations just for the beauty of categorization sounds unwise to me. For instance, I’m happy I can type ‘ls’ rather than ‘gnu core file list’. :-) Similarly, it’s not immediately obvious to me that something like “guix package edit” and “guix package install” would help newcomers. On the contrary, they would likely violate the rule of least surprise: most other tools provide sub-commands like “install”, some provide “edit” and “build” as well, without further categorization. >> Also, it’s not that simple: “guix size” can take a store item instead of >> a package name, “guix graph” cannot do it yet but it would be useful if >> it could (“guix graph -t references $(readlink -f /run/current-system)”), >> etc. > > Hm, OK, I'm not sure, but let's leave "graph" and "size" alone for now. But there are many other similar cases. For instance, ‘guix build’ can be passed a .drv; ‘guix archive’ can be passed a package name or a store file name, etc. Passing package names is a mere convenience for many of these commands; fundamentally, many operate on store items, derivations, etc. This requires careful consideration. >> I still think that having aliases like “guix install” as Andy proposed >> long ago would be useful, though I never started working on it. > > I agree! Except I think they should be inside "guix package": > > guix package install ... > guix package remove ... As I view it, the sole purpose of “guix install” and similar is to make it easier for newcomers to get started (see <http://xkcd.com/1654/>), and to allow users in general to type less. Adding “package” in the middle would probably defeat that goal. > As for the transactional operations (I mean remove/install in one > command), I think we can do it in a separate "guix profile" command: > > guix profile --install ... --remove ... This sounds good to me. >> There are probably other improvements to do around “guix package” (maybe >> turning some of its options into separate sub-commands as was suggested >> before.) All we need is a clear view of where we’re going and patches. :-) > > Here is the summary of the changes I think it would be good to have: > > | Replace this: | With this: | > |-----------------------------------+-----------------------------------| > | guix build | guix package build | I don’t like this one, for the reasons given above. > | guix edit | guix package definition¹ | > | guix import | guix package import | > | guix lint | guix package lint | > | guix refresh | guix package refresh | I suppose the benefit would be that users can type ‘guix package help’ and see all the sub-commands that relate to packages, right? > | guix package --show | guix package show | > | guix package --search | guix package search | > | guix package --list-available | guix package list | Or just ‘guix show’, ‘guix search’, etc.? > |-----------------------------------+-----------------------------------| > | guix package --list-generations | guix profile --list-generations | > | guix package --list-installed | guix profile --list-installed | > | guix package --delete-generations | guix profile --delete-generations | > | guix package --switch-generations | guix profile --switch-generations | > | guix package --roll-back | guix profile --roll-back | > | guix package --manifest | guix profile --manifest | > ¹ "edit" name is confusing: <http://bugs.gnu.org/22587> > > Maybe instead of --list-generations and others, these options should > transform into subcommands (list-generations) of "guix profile". I agree. But what should we do of transactions? Thoughts? Ludo’.
