Re: Reorganizing guix package commands

[Alex Kost]

Ludovic Courtès (2016-04-19 18:52 +0300) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Ludovic Courtès (2016-04-18 20:20 +0300) wrote:
>
> [...]
>
>>> I can see how adding “package” everywhere helps categorize things
>>> mentally, but as a user interface, I think it would be rather bad.
>>
>> As a user, I think it would be rather good.  (This is just my user opinion)
>
> To clarify, what I meant is that forcing users to type an additional
> word for common operations just for the beauty of categorization sounds
> unwise to me.

OK, I don't see it as "additional words", rather as "required words".
Typing "guix lint" for me is the same as "ip add".  It doesn't make
sense: "add" what?  It should be "ip address add"! (and "guix package
lint").

> For instance, I’m happy I can type ‘ls’ rather than ‘gnu core file list’.
> :-)

But we have a single "guix" command, while coreutils has many of them.
It is probably a matter of taste: I prefer to use a single and complex
"ip" command instead of route/ifconfig/netstat/...

> Similarly, it’s not immediately obvious to me that something like “guix
> package edit” and “guix package install” would help newcomers.
>
> On the contrary, they would likely violate the rule of least surprise:
> most other tools provide sub-commands like “install”, some provide
> “edit” and “build” as well, without further categorization.

It's because the other tools are poor, unfeatureful and unorganized :-)
I see "guix" as a more general tool than most others: it does not
operates only on packages, it does many other things, so it should have
reasonable subgroups, and (IMO) there shouldn't be such things as "guix
install" or "guix edit".

>>> 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.
>>
>> Hm, OK, I'm not sure, but let's leave "graph" and "size" alone for now.
>
> But there are many other similar cases.  For instance, ‘guix build’ can
> be passed a .drv; ‘guix archive’ can be passed a package name or a store
> file name, etc.
>
> Passing package names is a mere convenience for many of these commands;
> fundamentally, many operate on store items, derivations, etc.
>
> This requires careful consideration.

Definitely, I just raised some concerns and inconveniences I have using
"guix" command in a hope that it will lead to something productive.

OK, (although I still think that "guix package build" is better than
"guix build"), what about moving to "guix package" only those actions
that operate only on packages ("edit", "lint" and "refresh") or relate
only to packages ("import")?

>>> I still think that having aliases like “guix install” as Andy proposed
>>> long ago would be useful, though I never started working on it.
>>
>> I agree!  Except I think they should be inside "guix package":
>>
>>   guix package install ...
>>   guix package remove ...
>
> As I view it, the sole purpose of “guix install” and similar is to make
> it easier for newcomers to get started (see <http://xkcd.com/1654/>),
> and to allow users in general to type less.
>
> Adding “package” in the middle would probably defeat that goal.

OK, I see; then I don't like it.  Actually I don't really like to
duplicate (make aliases for) commands.  So if there will be "guix
profile remove", then I wouldn't like to have "guix package remove" or
"guix remove".

>> As for the transactional operations (I mean remove/install in one
>> command), I think we can do it in a separate "guix profile" command:
>>
>>   guix profile --install ... --remove ...
>
> This sounds good to me.
>
>>> 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.  :-)
>>
>> Here is the summary of the changes I think it would be good to have:
>>
>> | Replace this:                     | With this:                        |
>> |-----------------------------------+-----------------------------------|
>> | guix build                        | guix package build                |
>
> I don’t like this one, for the reasons given above.

OK.

>> | guix edit                         | guix package definition¹          |
>> | guix import                       | guix package import               |
>> | guix lint                         | guix package lint                 |
>> | guix refresh                      | guix package refresh              |
>
> I suppose the benefit would be that users can type ‘guix package help’
> and see all the sub-commands that relate to packages, right?

I didn't have this in mind, but it would be a good thing indeed.  As I
wrote above, these commands relate only to packages, you lint/edit a
*package*, and you import a *package* definition.

>> | guix package --show               | guix package show                 |
>> | guix package --search             | guix package search               |
>> | guix package --list-available     | guix package list                 |
>
> Or just ‘guix show’, ‘guix search’, etc.?

As for me, this would be worse than it is now.  You show/search
packages, not systems or licenses or whatever, so I think such things
should be subcommands for "guix package".

>> |-----------------------------------+-----------------------------------|
>> | guix package --list-generations   | guix profile --list-generations   |
>> | guix package --list-installed     | guix profile --list-installed     |
>> | guix package --delete-generations | guix profile --delete-generations |
>> | guix package --switch-generations | guix profile --switch-generations |
>> | guix package --roll-back          | guix profile --roll-back          |
>> | guix package --manifest           | guix profile --manifest           |
>
>> ¹ "edit" name is confusing: <http://bugs.gnu.org/22587>
>>
>> Maybe instead of --list-generations and others, these options should
>> transform into subcommands (list-generations) of "guix profile".
>
> I agree.  But what should we do of transactions?

Yes, that's a problem.  I don't have a clean picture of this.  Maybe
this:

  guix profile list-packages
  guix profile list-generations
  guix profile delete-generations
  guix profile switch-generation
  guix profile roll-back
  guix profile upgrade

For simple installing/removing:

  guix profile {add/install} PACKAGES...
  guix profile remove PACKAGES...

Complex transactions may be put in another subcommand, e.g.:

  guix profile manifest --install=PACKAGES,... --remove=PACKAGES,...

For manifest from file:

  guix profile manifest --file=...

Actually I don't really like all this, but I don't have better ideas, so
a simple decision for now (if it's reasonable) would be just separating
profile-related commands.  I mean moving the mentioned options from
"guix package" to "guix profile".

-- 
Alex