From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: Reorganizing guix package commands Date: Mon, 18 Apr 2016 17:50:14 -0400 Message-ID: <86bn56ziw9.fsf@gmail.com> References: <874mazi99k.fsf@gmail.com> <877ffual6i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asH4i-0004jF-EL for guix-devel@gnu.org; Mon, 18 Apr 2016 17:51:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asH4f-0001Z8-6j for guix-devel@gnu.org; Mon, 18 Apr 2016 17:51:20 -0400 Received: from plane.gmane.org ([80.91.229.3]:42984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asH4e-0001Yj-Sm for guix-devel@gnu.org; Mon, 18 Apr 2016 17:51:17 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1asH4P-0003eb-QL for guix-devel@gnu.org; Mon, 18 Apr 2016 23:51:01 +0200 Received: from c-73-167-118-254.hsd1.ma.comcast.net ([73.167.118.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2016 23:51:01 +0200 Received: from myglc2 by c-73-167-118-254.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2016 23:51:01 +0200 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org ludo@gnu.org (Ludovic Courtès) writes: > Alex Kost 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. A possibly better approach would be to explicitly split the guix command-verse into command classes to better match the structure of the doc and/or the class of the user. For example, per-user ('guix ...'), global-system ('guix-sys ...'), and developer ('guix-dev ...'), or something similar. Since the most frequently used commands will be per-user package management, I suggest you replace 'guix package' with 'guix' and promote the non-package commands to be hyphenated (ALA guix-daemon). This would, in turn, give rise to emacs functions something like: OLD NEW ------------------------------------------------------------------- user: guix-edit guix-view-definition guix-installed-packages guix-installed-packages guix-installed-user-packages NA admin: guix-installed-system-packages guix-sys-installed-packages developer: guix-hydra-build-list-latest-builds guix-dev-hydra-build-list-latest-builds guix-edit guix-dev-edit-definition While this would be not-so-nice for a power emacs user, it would make it easier for a less experienced user to find a relevant command in the sea of 'M-x guix-' commands in the *Completions* buffer. This kind of naming may not be typical in emacs, but I think it is probably justified considering the range of disparate functions provided by Guix, as discussed below. *** Regarding the bigger picture, and sorry this is so long, thinking more deeply about the situation, IMO, Guix usability challenges stem mostly from the fact that Guix provides an unexpectedly large range of functions: a per-user package manager, an OS, a system configuration tool, a packaging tool, a package editor, an installer, VM managers, developer utilities, hydra managers, and maybe some other things ;) Further, Guix behavior is modal, e.g., which functions work depend on how Guix was installed and/or configured. For example, in a Guix/Debian install, 'guix system reconfigure config.scm' churns away happily for 15 minutes and then produces the error, 'guix system: error: symlink: Permission denied: "/var/guix/profiles/system-1-link"' OTOH, other things you might not expect to work actually do, e.g. "guix init ..." will "upgrade" your Debian OS install to GuixSD ;) So, the problem goes well beyond function names. The underlying problem is that grouping such a large and disparate set of functions together in a single package is counter-intuitive. And further accessing them all under a single CLI/UI is challenging, to say the least. As a result, Guix is difficult to document and understand. The low user list activity is evidence that many potential users find the www doc intimidating and bail out before downloading. This may actually be OK since you are probably not ready for them anyhow. But users that do get as far as installing are confronted by 8 guix INFO entry points and 120+ "M-x guix-" functions. The only users that can be expected to work this way are Guix developers or, perhaps, hardened emacs criminals ;-) Others have trouble finding the relevant entry point, e.g, http://lists.gnu.org/archive/html/help-guix/2016-04/msg00056.html To summarize, Guix has a lot of functionality and complexity. So to be successful, we must consider carefully how to package and describe it. One way would be to split guix into ~three pieces. We could do this by clearly identifying the classes of users we expect to serve and then splitting out functions by user class. Something like sysadmin, end-user, and developer. This would probably be the simplest solution (for users, that is), but I imagine we don't want this. Alternatively, if we continue on the current path, we need to describe the new software paradigm that motivates placing these disparate functions together. We need to explain how the functions fit together. And we need to provide a map that helps each class of new user to find their way in. A while ago I took a crack at this: http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00674.html http://lists.gnu.org/archive/html/guix-devel/2016-03/pngM78VCHVVDp.png And it probably needs more work along the lines of explaining and motivating the paradigm. Ludo used a couple of ideas in this commit: http://lists.gnu.org/archive/html/guix-devel/2016-03/msg01038.html But I think we should revisit the original objective, which is to provide a brief illustrated Guix overview as an entry to all of Guix. Ideally this would provide a reference point in thinking about the questions raised above. - George