John Darrington <j...@darrington.wattle.id.au> writes: > On Mon, Apr 18, 2016 at 05:50:14PM -0400, myglc2 wrote: > l...@gnu.org (Ludovic Court??s) writes: > > > Alex Kost <alez...@gmail.com> 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.
