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

[Alex Kost <alezost@gmail.com>]

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 :-(

>>> 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.

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

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

-- 
Alex