Re: Reorganizing guix package commands

[myglc2]

John Darrington <address@hidden> writes:

> On Mon, Apr 18, 2016 at 05:50:14PM -0400, myglc2 wrote:
>      address@hidden (Ludovic Court??s) writes:
>      
>      > Alex Kost <address@hidden> skribis:
>      >
>      >> I've just sent a message to bug#22587??, but I realized it is better 
> to
>      >> discuss it here in a separate thread.
>      >>
>      >> So, I think there are inconsistencies in guix commands.  For example, 
> we
>      >> have "guix system build" to build a system, but "guix build" to build 
> a
>      >> package.  IMO "guix package build" would be a better choice.
>      >>
>      >> In general, I think it would be good to move package commands inside
>      >> "guix package", e.g, to make "guix package lint", "guix package size",
>      >> etc.
>      >
>      > Why not consider ???package??? to be the default word?  :-)
>      > I can see how adding ???package??? everywhere helps categorize things
>      > mentally, but as a user interface, I think it would be rather bad.
>      >
>      > 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.
>      >
>      > I still think that having aliases like ???guix install??? as Andy 
> proposed
>      > long ago would be useful, though I never started working on it.
>      >
>      > 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.  :-)
>      >
>      
>      I replied to the bug earlier, relevant parts are restated below, and a
>      discussion added below that.
>      
>      For overall Guix usability, the overloading of a single guix command for
>      everything is not so good. When you eventually create a man page, it
>      will be intimidating for someone just trying to do per-user package
>      management, which the majority of, and least sophisticated users, will
>      be trying to do.
>      
>      On the other hand there are several "classes" of commands as reflected
>      by the guix CLI being described in several logically different parts of
>      the doc. This structure is not so evident in the CLI structure.
>
> At the risk of taking this thread in a tanget ...
>
> I don't think the doc is particularly well structured, and will soon need a 
> major
> overhaul.

Agreed

> So I don't think it is a good model upon which to base the user interface..

Agreed^2. I was just using the fact of the doc structure to illustrate
that guix use is structured in ways not captured by $ guix ...

> While we're thinking about user interfaces, I believe a more abstract approach
> would be  better at this stage:    What types of person are going to be 
> interacting with Guix?  Developers?  Users?  Curious Bystanders?  Some other 
> category of person?  --- Each of those are probably going to have a core set
> of commands which they use regualarly,  a few which they use occasionally and
> some never.  Identifying those sets (which may intersect) is the first step
> to designing a good user interface.  That would help for both CLI and GUI.
>
>
> J'

This is not a tangent at all. The time to think user classes through and
adjust the interface is now. Otherwise we will be stuck with an
novice-overwhelming sea of functions that severely limits the adoption of
Guix.