Another cli interface for guix/sd

Another cli interface for guix/sd

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]

Héllo,

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

To help you avoid the need to read the above long thread here is
summary:

a) We need to do something regarding guix cli
b) We need to move commands inside "guix package"
b prime) we do not need to move commands inside "guix package" because it's
more to type.
c) We need to turn "guix package" options into separate sub-commands
d) We need to handle the fact that some commands operate on store items,
derivations, etc.
e) We need to avoid having 20 or something commands in the first level (*)
f) We need separate commands/cli for user and devs
f bis) We need a single "guix" full featured guix command
g) We need a "guix install" alias
h) Do we need to keep the ability add/remove packages in a single txn (* to
this I reply we should improve the profile generation manipulation with for
instance something like git rebase -i)
i) we must use flags/options/switches to nuance how a given command should
be executed
k) we should empower the user aka. one must understand how things works via
the cli

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.

Also, I did not look into it too much, but when I try to import guix inside
a guile REPL I can't. So my current work is in a fork of guix repository.
Is it possible to create a guix project without it being in the guix
repository?

Feedback welcome!

PS: the "xote" name comes from quixote.

[-- Attachment #2: Type: text/html, Size: 4991 bytes --]

Re: Another cli interface for guix/sd

[Ludovic Courtès]

Hi!

Amirouche Boubekki <amirouche.boubekki@gmail.com> 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’.