[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reorganizing guix package commands
From: |
Ludovic Courtès |
Subject: |
Re: Reorganizing guix package commands |
Date: |
Tue, 19 Apr 2016 17:52:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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.
For instance, I’m happy I can type ‘ls’ rather than ‘gnu core file list’.
:-)
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.
>> 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.
>> 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.
> 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.
> | 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?
> | 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.?
> |-----------------------------------+-----------------------------------|
> | 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?
Thoughts?
Ludo’.
- Re: Reorganizing guix package commands, (continued)
- Re: Reorganizing guix package commands, myglc2, 2016/04/19
- Re: Reorganizing guix package commands, Ricardo Wurmus, 2016/04/19
- Re: Reorganizing guix package commands, myglc2, 2016/04/19
- Re: Reorganizing guix package commands, Ricardo Wurmus, 2016/04/19
- Re: Reorganizing guix package commands,
Ludovic Courtès <=
- Re: Reorganizing guix package commands, Christopher Allan Webber, 2016/04/19
- Re: Reorganizing guix package commands, myglc2, 2016/04/19
- Re: Reorganizing guix package commands, John Darrington, 2016/04/20
- Re: Reorganizing guix package commands, Alex Kost, 2016/04/20
- Re: Reorganizing guix package commands, myglc2, 2016/04/20
- Re: Reorganizing guix package commands, Alex Kost, 2016/04/20
- Re: Reorganizing guix package commands, Taylan Ulrich Bayırlı/Kammer, 2016/04/20
- Re: Reorganizing guix package commands, Ludovic Courtès, 2016/04/20
- Re: Reorganizing guix package commands, myglc2, 2016/04/21
- Re: Reorganizing guix package commands, John Darrington, 2016/04/21