Re: Reorganizing guix package commands

[John Darrington]

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.  

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

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'
     

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature