bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change

[myglc2 <myglc2@gmail.com>]

Alex Kost <alezost@gmail.com> writes:

> myglc2 (2016-02-08 21:29 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> 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 <package>
or
guix view recipe <package>

guix edit manifest <manifest>

developer:
guix-dev edit definition <package>
or
guix-dev edit recipe <package>

> 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 ;-)