From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: bug#22587: =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?edit=E2=80=99?= & =?UTF-8?Q?=E2=80=98M-x?= guix-edit' typo, rename, & mode change Date: Mon, 18 Apr 2016 17:10:13 -0400 Message-ID: <86fuuizkqy.fsf@gmail.com> References: <8737t4jt1j.fsf@gmail.com> <87oabrr460.fsf@gmail.com> <87twlj6op5.fsf@gmail.com> <878u0bia77.fsf@gmail.com> 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]:42512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGSj-0003D9-Fd for bug-guix@gnu.org; Mon, 18 Apr 2016 17:12:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asGSg-0002Md-6i for bug-guix@gnu.org; Mon, 18 Apr 2016 17:12:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:55605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGSg-0002MU-3V for bug-guix@gnu.org; Mon, 18 Apr 2016 17:12:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1asGSf-0001Ej-W7 for bug-guix@gnu.org; Mon, 18 Apr 2016 17:12:02 -0400 In-Reply-To: <8737t4jt1j.fsf@gmail.com> Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGRn-0001NI-4L for bug-guix@gnu.org; Mon, 18 Apr 2016 17:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asGRj-0001dZ-PN for bug-guix@gnu.org; Mon, 18 Apr 2016 17:11:06 -0400 Received: from plane.gmane.org ([80.91.229.3]:40008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGRj-0001ct-F5 for bug-guix@gnu.org; Mon, 18 Apr 2016 17:11:03 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1asGRh-0000YH-N6 for bug-guix@gnu.org; Mon, 18 Apr 2016 23:11: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:11: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:11:01 +0200 List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 22587@debbugs.gnu.org Alex Kost writes: > myglc2 (2016-02-08 21:29 +0300) wrote: > >> Alex Kost writes: >> >>> myglc2 (2016-02-07 21:04 +0300) wrote: >>> >>>> From guix INFO: >>>> >>>> 6.2 Invoking ‘guix edit’ >>>> [...] >>>> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’ >>>> environment variable to edit the recipe of GCC 4.8.4 and that of Vim." >>>> >>>> TYPO: >>>> >>>> "edit" (last line above) should be replaced with "view", "inspect", or >>>> "examine". >>> >>> Just to mention - I like "edit" name :-) > > I changed my mind, I don't like it anymore :-( Good to hear. >>>> RENAME: >>>> >>>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the >>>> user will be able to modify the recipe, but this is not actually the >>>> case. The functions should be given a more informative and accurate >>>> name, such as: 'guix view', 'guix inspect', or 'guix examine'. >>> >>> Along with the package recipes that come with Guix, a user can also have >>> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and >>> "guix edit my-super-package" opens a user's file with this package. It >>> is highly likely that this file is editable, so "guix edit" is a perfect >>> name in this case I think. IMO it's a user responsibility to understand >>> what files can be edited and what cannot. >> >> Sorry this is so long, but I think this is a useability issue that is >> worth discussing more. >> >> I understand your point-of-view, but I think it is much more >> packager-centric than you should plan on your ultimate user base being. >> >> If we think about the mix of guix users when it is more widely >> successful, as I strongly believe it will be, a majority (80-90%) will >> be "simply" managing and configuring their computer and/or user >> account. They will NOT make packages. >> >> If this is the case, the majority of people clicking on "guix edit" will >> not understand "what files can be edited and what cannot." The very idea >> that a recipe on their computer can make something they need will be a >> radical leap. For these people, taking the fist look at a guix recipe >> will be a step deeper into guix. >> >> Such a user's first interaction might run along the lines of mine ... >> >> - Hmm, I want to see an actual recipe. >> >> - Oh wow, it says I can edit a recipe right here! >> >> - Hmm, maybe I shouldn't because I don't want to break something. >> >> - But they wouldn't call it "guix edit" if it wasn't OK to change stuff, >> right? >> >> - OK, I'll give it a shot. I'll look at something I am familiar with ... >> >> - 'guix edit screen' >> >> - WOW look at that. Finds the recipe, opens an editor, COOL! > [...] > > Now I agree with this. There was another person¹ who was confused by > "edit" name, and I think there will be more. OTOH if it will be renamed > to anything else, I'm afraid some people will still think they can just > modify the package definition in place. But "guix edit" is…, well, not > the best name we can have. > > Moreover, 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" (which is probably a different direction to Andy's > suggestion²), e.g, to make "guix package lint", "guix package size", > etc. 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 and this is reflected by the guix CLI being described in several logically different parts of the doc, but not, as you point out, by being differentiated in the CLI. A possibly better approach would be to explicitly split the guix command-verse into command classes to better match the structure of the doc. 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 think you should 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 user, it would make it easier for a less experienced user to find a relevant command in the sea of 'M-x commands' in the *Completions* buffer. This kind of naming may not be typical for emacs, but I think it is probably justified considering the range of functionality currently provided by Guix. > So, returning to "guix edit". I think any of: "view", "recipe", > "definition" are better. I would prefer "guix package definition", > not just "guix definition", as in future there may appear a way to > "edit" other things. For example, I've sent a patchset³ to go to > license definitions in Emacs. So analogously we could have "guix > license definition" (along with "guix license list" and similar). The best choice is probably the term that is most consistent with the doc and (hopefully some-day-existent) glossary. Based on present usage "definition" has stronger support (and BTW, "recipe" needs to be replaced with definition in a few places). I actually think "recipe" is more intuitive and better connotes the idea of a formula for making a package. But if you use recipe you should also change "definition" to "recipe" where appropriate in the doc. The other thing to consider is emacs support for editing manifests, which are weakly documented and supported now, but would surely be nice to have. So maybe ultimately something like: user: guix view definition or guix view recipe guix edit manifest developer: guix-dev edit definition or guix-dev edit recipe > I realize that making subcommands for "guix package" and removing "guix > graph", "guix lint" and other is radical, but I think it is the right > way to organize package commands. > > ¹ https://gnunet.org/bot/log/guix/2016-03-07#T948796 > ² http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00044.html > ³ http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00721.html Maybe radical changes are needed. Much easier to do now than later ;-)