Re: Another cli interface for guix/sd

[Ludovic Courtès]

Hi!

Amirouche Boubekki <address@hidden> skribis:

> This is a reply to a previous conversation that was started last year
> http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00724.html

[...]

> So I summed things in the following cli mockup:
>
> xote container attach NAME
> xote container init NAME SPEC
> xote container start NAME
>
> xote helper download URL
> xote helper hash FILE
>
> xote package archive export [-r] PACKAGE
> xote package archive import
> xote package build PACKAGE
> xote package challenge PACKAGE
> xote package edit PACKAGE
> xote package graph PACKAGE
> xote package import IMPORTER ARGS
> xote package lint PACKAGE
> xote package pack PACKAGE
> xote package size PACKAGE
> xote package search PACKAGE
>
> xote profile delete-generations
> xote profile enter
> xote profile init
> xote profile install
> xote profile leave
> xote profile list-generations
> xote profile list-installed
> xote profile manifest
> xote profile rebase
> xote profile refresh
> xote profile remove
> xote profile rollback
> xote profile switch-generations
>
> xote publish
>
> xote pull
>
> xote store gc
>
> xote system build
> xote system container
> xote system disk-image
> xote system extension-graph
> xote system init
> xote system reconfigure
> xote system refresh
> xote system rollback
> xote system shepherd-graph
> xote system switch-generation
> xote system vm
> xote system vm-image
>
> In particular:
>
> - guix environement is gone, because it can be replaced with guix profile
> - I think the cli should reflect the underlying inner working but also the
> usage. For instance, one might argue that containers are just systems (or
> profiles) but for the user it makes a great difference to have the commands
> spread as several multiple commands instead of a single command that does
> everything required.
> - There is surely missing commands in the "store" section, input welcome!
> - There is two single commands without subcommands called "pull" and
> "publish". I am not sure where to put them.

I think this does not address one of my main concerns in the previous
discussion, which is that we’re talking about a interface for users, and
that this should obey different rules and an API or a formal
categorization.

One of these rules is conciseness.  ‘guix helper download’ and ‘guix
package edit’ are good examples of what I think should be avoided.  :-)

Another rule IMO is to have commands that remind users of use cases,
rather than internal implementation aspects.  For instance, I find ‘guix
profile enter’ to be potentially less clear than ‘guix environment’ in
that respect.

Another thing that makes strict categorization inappropriate in my eye
is that many commands can take either a package name or a store file
name.  That’s the case of ‘guix build’, ‘guix size’, ‘guix graph’, and
probably others.  Thus putting them under the ‘package’ category is not
quite accurate; they’d need to appear in a second directory as well.


For a start, I think we should focus on ‘guix package’ since there’s
consensus that it does too much.  What do we leave in it?  What do we
take out?  Should we add a ‘guix profile’ command to deal with
generations, but not to install/remove/upgrade packages?

Similarly, as has been discussed before, we should probably add ‘guix
install’, ‘guix remove’, and ‘guix upgrade’ aliases that do what we
would expect.

Thoughts?

Thanks,
Ludo’.