Reorganizing guix package commands

Reorganizing guix package commands

[Alex Kost]

I've just sent a message to bug#22587¹, but I realized it is better to
discuss it here in a separate thread.

So, 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", e.g, to make "guix package lint", "guix package size",
etc.

Wouldn't it be great to make some breaking changes?  I mean if this or
any other proposal on "guix" command structure is reasonable, I think
it's just the time for it while Guix is still alpha/beta.  Otherwise,
the current command structure will never be changed.

¹ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22587#29

-- 
Alex

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On Mon, Apr 18, 2016 at 11:57:59AM +0300, Alex Kost wrote:
     I've just sent a message to bug#22587??, but I realized it is better to
     discuss it here in a separate thread.
     
     So, 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", e.g, to make "guix package lint", "guix package size",
     etc.

I'm not saying that you're wrong.  But I think the idea is that guix build
is a command for development, whereas guix package is a command for users.
I think the two need to be kept separate.


     Wouldn't it be great to make some breaking changes?  I mean if this or
     any other proposal on "guix" command structure is reasonable, I think
     it's just the time for it while Guix is still alpha/beta.  Otherwise,
     the current command structure will never be changed.


I wouldn't mind seeing a few of the more recent commands as options to 
(a possibly renamed) guix build.  For example it seems to me that guix
environment is specific to a package so perhaps that is a good candidate.

But I don't know.  Maybe it's still too early to make changes.  If such
changes are to be made, then we should get them right.

J'
     

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[Alex Kost]

John Darrington (2016-04-18 19:10 +0300) wrote:

> On Mon, Apr 18, 2016 at 11:57:59AM +0300, Alex Kost wrote:
>      I've just sent a message to bug#22587??, but I realized it is better to
>      discuss it here in a separate thread.
>
>      So, 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", e.g, to make "guix package lint", "guix package size",
>      etc.
>
> I'm not saying that you're wrong.  But I think the idea is that guix build
> is a command for development, whereas guix package is a command for users.
> I think the two need to be kept separate.

Sorry, I don't understand this point: we all are users of "guix"
command.  It looks natural to me that when you want to build a system,
you write "guix system build", and when you want to build a package, you
write "guix package build"; when you want to install a package, you
can write "guix package install".  Why a user wouldn't want just to
build a package?  For example, I do it all the time when I want just to
try a package without installing.

>      Wouldn't it be great to make some breaking changes?  I mean if this or
>      any other proposal on "guix" command structure is reasonable, I think
>      it's just the time for it while Guix is still alpha/beta.  Otherwise,
>      the current command structure will never be changed.
>
>
> I wouldn't mind seeing a few of the more recent commands as options to
> (a possibly renamed) guix build.  For example it seems to me that guix
> environment is specific to a package so perhaps that is a good candidate.

Wow, I have a reverse impression: I think "guix environment" is the
worst candidate for moving elsewhere (I mean it is good as it is now)
and it should stay as a stand-alone command.

-- 
Alex

Re: Reorganizing guix package commands

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> I've just sent a message to bug#22587¹, but I realized it is better to
> discuss it here in a separate thread.
>
> So, 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", e.g, to make "guix package lint", "guix package size",
> etc.

Why not consider “package” to be the default word?  :-)
I can see how adding “package” everywhere helps categorize things
mentally, but as a user interface, I think it would be rather bad.

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.

I still think that having aliases like “guix install” as Andy proposed
long ago would be useful, though I never started working on it.

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

> Wouldn't it be great to make some breaking changes?  I mean if this or
> any other proposal on "guix" command structure is reasonable, I think
> it's just the time for it while Guix is still alpha/beta.  Otherwise,
> the current command structure will never be changed.

I agree, now is the right time to break everything!  ;-)

Ludo’.

Re: Reorganizing guix package commands

[myglc2]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Kost <alezost@gmail.com> skribis:
>
>> I've just sent a message to bug#22587¹, but I realized it is better to
>> discuss it here in a separate thread.
>>
>> So, 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", e.g, to make "guix package lint", "guix package size",
>> etc.
>
> Why not consider “package” to be the default word?  :-)
> I can see how adding “package” everywhere helps categorize things
> mentally, but as a user interface, I think it would be rather bad.
>
> 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.
>
> I still think that having aliases like “guix install” as Andy proposed
> long ago would be useful, though I never started working on it.
>
> 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.  :-)
>

I replied to the bug earlier, relevant parts are restated below, and a
discussion added below that.

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 as reflected
by the guix CLI being described in several logically different parts of
the doc. This structure is not so evident in the CLI structure.

A possibly better approach would be to explicitly split the guix
command-verse into command classes to better match the structure of the
doc and/or the class of the user. 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 suggest you 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 emacs user, it would make it
easier for a less experienced user to find a relevant command in the sea
of 'M-x guix-' commands in the *Completions* buffer.  This kind of
naming may not be typical in emacs, but I think it is probably justified
considering the range of disparate functions provided by Guix, as
discussed below.

***

Regarding the bigger picture, and sorry this is so long, thinking more
deeply about the situation, IMO, Guix usability challenges stem mostly
from the fact that Guix provides an unexpectedly large range of
functions: a per-user package manager, an OS, a system configuration
tool, a packaging tool, a package editor, an installer, VM managers,
developer utilities, hydra managers, and maybe some other things ;)

Further, Guix behavior is modal, e.g., which functions work depend on
how Guix was installed and/or configured. For example, in a Guix/Debian
install, 'guix system reconfigure config.scm' churns away happily for 15
minutes and then produces the error, 'guix system: error: symlink:
Permission denied: "/var/guix/profiles/system-1-link"'

OTOH, other things you might not expect to work actually do, e.g.  "guix
init ..."  will "upgrade" your Debian OS install to GuixSD ;)

So, the problem goes well beyond function names. The underlying problem
is that grouping such a large and disparate set of functions together in
a single package is counter-intuitive. And further accessing them all
under a single CLI/UI is challenging, to say the least.

As a result, Guix is difficult to document and understand.  The low user
list activity is evidence that many potential users find the www doc
intimidating and bail out before downloading. This may actually be OK
since you are probably not ready for them anyhow.

But users that do get as far as installing are confronted by 8 guix INFO
entry points and 120+ "M-x guix-" functions.  The only users that can be
expected to work this way are Guix developers or, perhaps, hardened
emacs criminals ;-) Others have trouble finding the relevant entry
point, e.g,

http://lists.gnu.org/archive/html/help-guix/2016-04/msg00056.html

To summarize, Guix has a lot of functionality and complexity. So to be
successful, we must consider carefully how to package and describe it.

One way would be to split guix into ~three pieces.  We could do this by
clearly identifying the classes of users we expect to serve and then
splitting out functions by user class.  Something like sysadmin,
end-user, and developer. This would probably be the simplest solution
(for users, that is), but I imagine we don't want this.

Alternatively, if we continue on the current path, we need to describe
the new software paradigm that motivates placing these disparate
functions together.  We need to explain how the functions fit
together. And we need to provide a map that helps each class of new user
to find their way in.

A while ago I took a crack at this:

http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00674.html

http://lists.gnu.org/archive/html/guix-devel/2016-03/pngM78VCHVVDp.png

And it probably needs more work along the lines of explaining and
motivating the paradigm. Ludo used a couple of ideas in this commit:

http://lists.gnu.org/archive/html/guix-devel/2016-03/msg01038.html

But I think we should revisit the original objective, which is to
provide a brief illustrated Guix overview as an entry to all of
Guix.

Ideally this would provide a reference point in thinking about the
questions raised above. - George

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 3360 bytes --]

On Mon, Apr 18, 2016 at 05:50:14PM -0400, myglc2 wrote:
     ludo@gnu.org (Ludovic Court??s) writes:
     
     > Alex Kost <alezost@gmail.com> skribis:
     >
     >> I've just sent a message to bug#22587??, but I realized it is better to
     >> discuss it here in a separate thread.
     >>
     >> So, 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", e.g, to make "guix package lint", "guix package size",
     >> etc.
     >
     > Why not consider ???package??? to be the default word?  :-)
     > I can see how adding ???package??? everywhere helps categorize things
     > mentally, but as a user interface, I think it would be rather bad.
     >
     > 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.
     >
     > I still think that having aliases like ???guix install??? as Andy proposed
     > long ago would be useful, though I never started working on it.
     >
     > 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.  :-)
     >
     
     I replied to the bug earlier, relevant parts are restated below, and a
     discussion added below that.
     
     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 as reflected
     by the guix CLI being described in several logically different parts of
     the doc. This structure is not so evident in the CLI structure.

At the risk of taking this thread in a tanget ...

I don't think the doc is particularly well structured, and will soon need a major
overhaul.  

So I don't think it is a good model upon which to base the user interface..

While we're thinking about user interfaces, I believe a more abstract approach
would be  better at this stage:    What types of person are going to be 
interacting with Guix?  Developers?  Users?  Curious Bystanders?  Some other 
category of person?  --- Each of those are probably going to have a core set
of commands which they use regualarly,  a few which they use occasionally and
some never.  Identifying those sets (which may intersect) is the first step
to designing a good user interface.  That would help for both CLI and GUI.


J'
     

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[myglc2]

John Darrington <john@darrington.wattle.id.au> writes:

> On Mon, Apr 18, 2016 at 05:50:14PM -0400, myglc2 wrote:
>      ludo@gnu.org (Ludovic Court??s) writes:
>      
>      > Alex Kost <alezost@gmail.com> skribis:
>      >
>      >> I've just sent a message to bug#22587??, but I realized it is better to
>      >> discuss it here in a separate thread.
>      >>
>      >> So, 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", e.g, to make "guix package lint", "guix package size",
>      >> etc.
>      >
>      > Why not consider ???package??? to be the default word?  :-)
>      > I can see how adding ???package??? everywhere helps categorize things
>      > mentally, but as a user interface, I think it would be rather bad.
>      >
>      > 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.
>      >
>      > I still think that having aliases like ???guix install??? as Andy proposed
>      > long ago would be useful, though I never started working on it.
>      >
>      > 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.  :-)
>      >
>      
>      I replied to the bug earlier, relevant parts are restated below, and a
>      discussion added below that.
>      
>      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 as reflected
>      by the guix CLI being described in several logically different parts of
>      the doc. This structure is not so evident in the CLI structure.
>
> At the risk of taking this thread in a tanget ...
>
> I don't think the doc is particularly well structured, and will soon need a major
> overhaul.

Agreed

> So I don't think it is a good model upon which to base the user interface..

Agreed^2. I was just using the fact of the doc structure to illustrate
that guix use is structured in ways not captured by $ guix ...

> While we're thinking about user interfaces, I believe a more abstract approach
> would be  better at this stage:    What types of person are going to be 
> interacting with Guix?  Developers?  Users?  Curious Bystanders?  Some other 
> category of person?  --- Each of those are probably going to have a core set
> of commands which they use regualarly,  a few which they use occasionally and
> some never.  Identifying those sets (which may intersect) is the first step
> to designing a good user interface.  That would help for both CLI and GUI.
>
>
> J'

This is not a tangent at all. The time to think user classes through and
adjust the interface is now. Otherwise we will be stuck with an
novice-overwhelming sea of functions that severely limits the adoption of
Guix.

Re: Reorganizing guix package commands

[Thompson, David]

I'm with Ricardo.  Separating things into things for "users" and
things for "developers" just re-establishes the dichotomy that we
intend to blur, and insist isn't really there in the first place.  We
want to encourage users to hack the system, not cordon off a section
of tools and say "these aren't for you."  Surely there are
improvements that can be made without sacrificing this.  The
conventional school of usability is not focused on making users more
computer literate, so we need to take a different route.

- Dave

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

On Tue, Apr 19, 2016 at 09:03:30AM -0400, Thompson, David wrote:
     I'm with Ricardo.  Separating things into things for "users" and
     things for "developers" just re-establishes the dichotomy that we
     intend to blur, and insist isn't really there in the first place.  We
     want to encourage users to hack the system, not cordon off a section
     of tools and say "these aren't for you."  Surely there are
     improvements that can be made without sacrificing this.  The
     conventional school of usability is not focused on making users more
     computer literate, so we need to take a different route.
     
I do take your point here, and I am fully in agreement that the distinction
between users and developers is an artificial one which we should not maintain.
But there are always going to be categories of tasks which are closely related
to one another, other tasks which are only loosely related and some which are
not related at all.

The idea is to make the user interface intuitive, not to dissuade people from 
using them.

J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[myglc2]

"Thompson, David" <dthompson2@worcester.edu> writes:

> I'm with Ricardo.  Separating things into things for "users" and
> things for "developers" just re-establishes the dichotomy that we
> intend to blur, and insist isn't really there in the first place.  We
> want to encourage users to hack the system, not cordon off a section
> of tools and say "these aren't for you."

On this point you Guix developers are so didactic that you run a real
risk of making Guix adoption self-limiting :-(

And you misunderstand what I am proposing. Instead I am saying that
restructuring the interface can make it easier for a novice to find
their way in. Once this novice is using Guix, the same structuring will
help them find and use other parts of Guix.

This actually advances your objective because it brings more potential
"system hackers" into the user base.  How is this bad?

Re: Reorganizing guix package commands

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> While we're thinking about user interfaces, I believe a more abstract approach
> would be  better at this stage:    What types of person are going to be 
> interacting with Guix?  Developers?  Users?  Curious Bystanders?  Some other 
> category of person?  --- Each of those are probably going to have a core set
> of commands which they use regualarly,  a few which they use occasionally and
> some never.  Identifying those sets (which may intersect) is the first step
> to designing a good user interface.  That would help for both CLI and GUI.

I and others tried to start each of the “Invoking” sections with a
sentence clarifying the intended audience of the command.

Probably we should try to reflect it more in the manual’s structure, so
it’s not clear to me exactly how.

Ludo’.

Re: Reorganizing guix package commands

[Alex Kost]

myglc2 (2016-04-19 00:50 +0300) wrote:

> 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 as reflected
> by the guix CLI being described in several logically different parts of
> the doc. This structure is not so evident in the CLI structure.
>
> A possibly better approach would be to explicitly split the guix
> command-verse into command classes to better match the structure of the
> doc and/or the class of the user. For example, per-user ('guix ...'),
> global-system ('guix-sys ...'), and developer ('guix-dev ...'), or
> something similar.

Sorry, but I can't agree with this.  I don't see a difference between
"simple users" and developers.  Guix provides many tools indeed, but I
don't think they should be organized in groups depending on "user
classes".

I like that all the tools are placed in a single "guix" command, I just
would like to reorganize it a bit (or a lot :-)).

-- 
Alex

Re: Reorganizing guix package commands

[Ricardo Wurmus]

Alex Kost <alezost@gmail.com> writes:

> myglc2 (2016-04-19 00:50 +0300) wrote:
>
>> 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 as reflected
>> by the guix CLI being described in several logically different parts of
>> the doc. This structure is not so evident in the CLI structure.
>>
>> A possibly better approach would be to explicitly split the guix
>> command-verse into command classes to better match the structure of the
>> doc and/or the class of the user. For example, per-user ('guix ...'),
>> global-system ('guix-sys ...'), and developer ('guix-dev ...'), or
>> something similar.
>
> Sorry, but I can't agree with this.  I don't see a difference between
> "simple users" and developers.  Guix provides many tools indeed, but I
> don't think they should be organized in groups depending on "user
> classes".

I agree with Alex.  In tools like Emacs we also don’t see this arbitrary
distinction between simple users and advanced users or developers.
That’s the same spirit in Guix.

I do agree that the documentation needs reorganization, and there have
been proposals for that already. 

> I like that all the tools are placed in a single "guix" command, I just
> would like to reorganize it a bit (or a lot :-)).

I agree, but since I don’t have any well-thought-out proposals on how to
improve I’m just quietly following this conversation.

~~ Ricardo

Re: Reorganizing guix package commands

[myglc2]

Alex Kost <alezost@gmail.com> writes:

> myglc2 (2016-04-19 00:50 +0300) wrote:
>
>> 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 as reflected
>> by the guix CLI being described in several logically different parts of
>> the doc. This structure is not so evident in the CLI structure.
>>
>> A possibly better approach would be to explicitly split the guix
>> command-verse into command classes to better match the structure of the
>> doc and/or the class of the user. For example, per-user ('guix ...'),
>> global-system ('guix-sys ...'), and developer ('guix-dev ...'), or
>> something similar.
>
> Sorry, but I can't agree with this.  I don't see a difference between
> "simple users" and developers.  Guix provides many tools indeed, but I
> don't think they should be organized in groups depending on "user
> classes".
>
> I like that all the tools are placed in a single "guix" command, I just
> would like to reorganize it a bit (or a lot :-)).

Yes, of course, you have reacted as I predicted ...

>> While this would be not-so-nice for a power emacs user, ...

But user interface design involves trade-offs. If you design the
interface only for power users that is all you will ever have.

The adjustments I have suggested are easily accommodated by a power user
and meanwhile make Guix much more approachable for a novice.

The problem you face as you set the Guix interface in stone is that you
have inadequate representation of novices in the discussion.

If you are not careful you will harden Guix into a ninja tool and this
will severely limit it's adoption.

You need to remember that, at the end of the day, how important Guix is
will depend on how many users it has.

Re: Reorganizing guix package commands

[Alex Kost]

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

> Alex Kost <alezost@gmail.com> skribis:
>
>> I've just sent a message to bug#22587¹, but I realized it is better to
>> discuss it here in a separate thread.
>>
>> So, 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", e.g, to make "guix package lint", "guix package size",
>> etc.
>
> Why not consider “package” to be the default word?  :-)

Interesting, but why do we need to have "guix package" at all?  Let's
just use "guix --install", etc.  (This is not what I suggest :-))

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

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

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

> 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                |
| guix edit                         | guix package definition¹          |
| guix import                       | guix package import               |
| guix lint                         | guix package lint                 |
| guix refresh                      | guix package refresh              |
| guix package --show               | guix package show                 |
| guix package --search             | guix package search               |
| guix package --list-available     | guix package list                 |
|-----------------------------------+-----------------------------------|
| 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".

-- 
Alex

Re: Reorganizing guix package commands

[Taylan Ulrich Bayırlı/Kammer]

Alex Kost <alezost@gmail.com> writes:

> Here is the summary of the changes I think it would be good to have:
>
> | Replace this:                     | With this:                        |
> |-----------------------------------+-----------------------------------|
> | guix build                        | guix package build                |
> | guix edit                         | guix package definition¹          |
> | guix import                       | guix package import               |
> | guix lint                         | guix package lint                 |
> | guix refresh                      | guix package refresh              |
> | guix package --show               | guix package show                 |
> | guix package --search             | guix package search               |
> | guix package --list-available     | guix package list                 |
> |-----------------------------------+-----------------------------------|
> | 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>

How about "view"?  ("Definition" is so long.)

> Maybe instead of --list-generations and others, these options should
> transform into subcommands (list-generations) of "guix profile".

Yeah, seems more consistent.


I don't have a strong opinion on this whole thing but I think a clear
and logical categorization like the above would be a good base.  One
could then add abbreviations on top of it like:

    guix install -> guix package install

Hmm, or does 'install' belong to 'profile'?  Or should the whole thing
be called 'guix profile add'?  "Install" kinda implies that something
new will be installed into the system, rather than just some symlinks
shuffled.  (One can see the building or downloading as a special case /
transparent handling of the case where the package to be added to the
profile is not in the store yet.)

BTW if it is to become e.g. 'guix profile add', then combining an
add/remove in one transaction (if it's important to keep that feature)
could look like:

    guix package add foo bar -- remove baz bat

/bikeshedding :-)

Taylan

Re: Reorganizing guix package commands

[Alex Kost]

Taylan Ulrich "Bayırlı/Kammer" (2016-04-19 12:17 +0300) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> Here is the summary of the changes I think it would be good to have:
>>
>> | Replace this:                     | With this:                        |
>> |-----------------------------------+-----------------------------------|
>> | guix build                        | guix package build                |
>> | guix edit                         | guix package definition¹          |
>> | guix import                       | guix package import               |
>> | guix lint                         | guix package lint                 |
>> | guix refresh                      | guix package refresh              |
>> | guix package --show               | guix package show                 |
>> | guix package --search             | guix package search               |
>> | guix package --list-available     | guix package list                 |
>> |-----------------------------------+-----------------------------------|
>> | 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>
>
> How about "view"?  ("Definition" is so long.)

I prefer "definition", but it's just my opinion.  Maybe we can use the
same feature as some other software use, like you can write: "ip
address" or "ip addr" or even "ip a".  I.e., if some portion of
characters defines a subcommand name unambiguously, it's ok to use.  So
this could become "guix package def" or "guix package d" if there will
be no other subcommands beginning with "d".

I think it would be a great feature (I already wish to write "guix env"
or "guix sy re" :-)).  I think it is for a separate thread though.

>> Maybe instead of --list-generations and others, these options should
>> transform into subcommands (list-generations) of "guix profile".
>
> Yeah, seems more consistent.
>
> I don't have a strong opinion on this whole thing but I think a clear
> and logical categorization like the above would be a good base.  One
> could then add abbreviations on top of it like:
>
>     guix install -> guix package install
>
> Hmm, or does 'install' belong to 'profile'?  Or should the whole thing
> be called 'guix profile add'?  "Install" kinda implies that something
> new will be installed into the system, rather than just some symlinks
> shuffled.  (One can see the building or downloading as a special case /
> transparent handling of the case where the package to be added to the
> profile is not in the store yet.)

Yes, this is controversial.  I think it would be clean to separate
profile stuff into a separate command ("guix profile").  As for adding
"guix package install/remove", I don't really know.

> BTW if it is to become e.g. 'guix profile add', then combining an
> add/remove in one transaction (if it's important to keep that feature)

I think this is a very important feature.

> could look like:
>
>     guix package add foo bar -- remove baz bat

To be honest I don't like it.  There is also "upgrade" which can be
performed along with install and remove.

But I like "--add" instead of or along with (as they may just co-exist
and do the same thing) "--install" in a potential "guix profile"
command.

-- 
Alex

Re: Reorganizing guix package commands

[Hartmut Goebel]

Am 19.04.2016 um 09:52 schrieb Alex Kost:

I like you suggestion, except for these:
> Here is the summary of the changes I think it would be good to have:
>
> [...]
> |-----------------------------------+-----------------------------------|
> | guix package --list-generations   | guix profile --list-generations   |

Why no replace the dashes here, too? This would IMHO be more consistent
to the package sub-command?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Reorganizing guix package commands

[Alex Kost]

Hartmut Goebel (2016-04-19 12:23 +0300) wrote:

> Am 19.04.2016 um 09:52 schrieb Alex Kost:
>
> I like you suggestion, except for these:
>> Here is the summary of the changes I think it would be good to have:
>>
>> [...]
>> |-----------------------------------+-----------------------------------|
>> | guix package --list-generations   | guix profile --list-generations   |
>
> Why no replace the dashes here, too? This would IMHO be more consistent
> to the package sub-command?

I agree, especially taking into account that there is "guix system
list-generations".  Then the same should probably be done with other
things (list-installed, roll-back, ...)

-- 
Alex

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Tue, Apr 19, 2016 at 11:23:43AM +0200, Hartmut Goebel wrote:
     Am 19.04.2016 um 09:52 schrieb Alex Kost:
     
     I like you suggestion, except for these:
     > Here is the summary of the changes I think it would be good to have:
     >
     > [...]
     > |-----------------------------------+-----------------------------------|
     > | guix package --list-generations   | guix profile --list-generations   |
     
     Why no replace the dashes here, too? This would IMHO be more consistent
     to the package sub-command?
     
I beleive the dashes should be removed, since list-generations is a requested 
action, not an option.  In Unix like systems we have the commands rm, ls, mv; NOT 
file --remove, file --list and file --move

But I know that some people like to use options for commands.

One possibility would be to have a set of standard aliases.  Then people who like
guix package --list-generations ; or
guix system --frobnicate
can use that.

Others can use

guixp-lg ; or
guixs-fb

This was the method used by aegis for many years and kept most people happy.

J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[myglc2]

Alex Kost <alezost@gmail.com> writes:

> Ludovic Courtès (2016-04-18 20:20 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> I've just sent a message to bug#22587¹, but I realized it is better to
>>> discuss it here in a separate thread.
>>>
>>> So, 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", e.g, to make "guix package lint", "guix package size",
>>> etc.
>>
>> Why not consider “package” to be the default word?  :-)
>
> Interesting, but why do we need to have "guix package" at all?  Let's
> just use "guix --install", etc.  (This is not what I suggest :-))
>
>> 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)
>
>> 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.
>
>> 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 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 ...
>
>> 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                |
> | guix edit                         | guix package definition¹          |
> | guix import                       | guix package import               |
> | guix lint                         | guix package lint                 |
> | guix refresh                      | guix package refresh              |
> | guix package --show               | guix package show                 |
> | guix package --search             | guix package search               |
> | guix package --list-available     | guix package list                 |
> |-----------------------------------+-----------------------------------|
> | 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".

The term 'profile' is used at user- and system- levels:

3.1 Features
============
[...]
   Instead of referring to these directories, users have their own
“profile”, which points to the packages that they actually want to use.
These profiles are stored within each user’s home directory, at
‘$HOME/.guix-profile’.

7.2.2 ‘operating-system’ Reference
----------------------------------
     ‘packages’ (default: %BASE-PACKAGES)
          The set of packages installed in the global profile, which is
          accessible at ‘/run/current-system/profile’.

... and in home directories:

/home/user1/.guix-profile -> /var/guix/profiles/per-user/user1/guix-profile
/home/user1/.profile

Making the use of 'profile' here ambiguous. So I suggest that you change
'guix profile ...' to 'guix user ...' like so:

|-----------------------------------+--------------------------------|
| guix package --list-generations   | guix user --list-generations   |
| guix package --list-installed     | guix user --list-installed     |
| guix package --delete-generations | guix user --delete-generations |
| guix package --switch-generations | guix user --switch-generations |
| guix package --roll-back          | guix user --roll-back          |
| guix package --manifest           | guix user --manifest           |

and similarly, the above ...

>   guix package install ...
>   guix package remove ...

... would become ...

guix user install ...
guix user remove ...

Re: Reorganizing guix package commands

[Ricardo Wurmus]

myglc2 <myglc2@gmail.com> writes:

> Alex Kost <alezost@gmail.com> writes:
>
>> Ludovic Courtès (2016-04-18 20:20 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> I've just sent a message to bug#22587¹, but I realized it is better to
>>>> discuss it here in a separate thread.
>>>>
>>>> So, 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", e.g, to make "guix package lint", "guix package size",
>>>> etc.
>>>
>>> Why not consider “package” to be the default word?  :-)
>>
>> Interesting, but why do we need to have "guix package" at all?  Let's
>> just use "guix --install", etc.  (This is not what I suggest :-))
>>
>>> 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)
>>
>>> 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.
>>
>>> 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 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 ...
>>
>>> 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                |
>> | guix edit                         | guix package definition¹          |
>> | guix import                       | guix package import               |
>> | guix lint                         | guix package lint                 |
>> | guix refresh                      | guix package refresh              |
>> | guix package --show               | guix package show                 |
>> | guix package --search             | guix package search               |
>> | guix package --list-available     | guix package list                 |
>> |-----------------------------------+-----------------------------------|
>> | 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".
>
> The term 'profile' is used at user- and system- levels:
>
> 3.1 Features
> ============
> [...]
>    Instead of referring to these directories, users have their own
> “profile”, which points to the packages that they actually want to use.
> These profiles are stored within each user’s home directory, at
> ‘$HOME/.guix-profile’.
>
> 7.2.2 ‘operating-system’ Reference
> ----------------------------------
>      ‘packages’ (default: %BASE-PACKAGES)
>           The set of packages installed in the global profile, which is
>           accessible at ‘/run/current-system/profile’.
>
> ... and in home directories:
>
> /home/user1/.guix-profile -> /var/guix/profiles/per-user/user1/guix-profile
> /home/user1/.profile
>
> Making the use of 'profile' here ambiguous. So I suggest that you change
> 'guix profile ...' to 'guix user ...' like so:

I don’t think it’s ambiguous at all.  The system profile is a profile
like any other, so you can, for example, list installed packages like
this:

    guix package -p /run/booted-system/profile \
      --list-installed

What doesn’t work is to operate on generations because the booted-system
profile is a direct link to a store item; there is no indirection.  You
also cannot use “--manifest” on it because the profile contents are
controlled via “guix system reconfigure /path/to/config.scm”.

Rather than making the differences bigger, I think we should unify
profile management, i.e. make more of the commands for regular profiles
work with the system profile (provided a user has root privileges).

> |-----------------------------------+--------------------------------|
> | guix package --list-generations   | guix user --list-generations   |
> | guix package --list-installed     | guix user --list-installed     |
> | guix package --delete-generations | guix user --delete-generations |
> | guix package --switch-generations | guix user --switch-generations |
> | guix package --roll-back          | guix user --roll-back          |
> | guix package --manifest           | guix user --manifest           |
>
> and similarly, the above ...
>
>>   guix package install ...
>>   guix package remove ...
>
> ... would become ...
>
> guix user install ...
> guix user remove ...

I don’t think this is a good idea.  In addition to the reasons I stated
above “user” is even more vague than “package” is.  The proposal to use
“profile” for profile-related operations is a very natural one.

Here at the MDC we are using many different profiles on a regular
basis.  Multiple profiles is a common use-case.  Operating on profiles
with “guix profile” seems really appropriate; doing this via “guix user”
is confusing to me.  I don’t know what “user” stands for.

~~ Ricardo

Re: Reorganizing guix package commands

[myglc2]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> Ludovic Courtès (2016-04-18 20:20 +0300) wrote:
>>>
>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>
>>>>> I've just sent a message to bug#22587¹, but I realized it is better to
>>>>> discuss it here in a separate thread.
>>>>>
>>>>> So, 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", e.g, to make "guix package lint", "guix package size",
>>>>> etc.
>>>>
>>>> Why not consider “package” to be the default word?  :-)
>>>
>>> Interesting, but why do we need to have "guix package" at all?  Let's
>>> just use "guix --install", etc.  (This is not what I suggest :-))
>>>
>>>> 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)
>>>
>>>> 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.
>>>
>>>> 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 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 ...
>>>
>>>> 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                |
>>> | guix edit                         | guix package definition¹          |
>>> | guix import                       | guix package import               |
>>> | guix lint                         | guix package lint                 |
>>> | guix refresh                      | guix package refresh              |
>>> | guix package --show               | guix package show                 |
>>> | guix package --search             | guix package search               |
>>> | guix package --list-available     | guix package list                 |
>>> |-----------------------------------+-----------------------------------|
>>> | 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".
>>
>> The term 'profile' is used at user- and system- levels:
>>
>> 3.1 Features
>> ============
>> [...]
>>    Instead of referring to these directories, users have their own
>> “profile”, which points to the packages that they actually want to use.
>> These profiles are stored within each user’s home directory, at
>> ‘$HOME/.guix-profile’.
>>
>> 7.2.2 ‘operating-system’ Reference
>> ----------------------------------
>>      ‘packages’ (default: %BASE-PACKAGES)
>>           The set of packages installed in the global profile, which is
>>           accessible at ‘/run/current-system/profile’.
>>
>> ... and in home directories:
>>
>> /home/user1/.guix-profile -> /var/guix/profiles/per-user/user1/guix-profile
>> /home/user1/.profile
>>
>> Making the use of 'profile' here ambiguous. So I suggest that you change
>> 'guix profile ...' to 'guix user ...' like so:
>
> I don’t think it’s ambiguous at all.  The system profile is a profile
> like any other, so you can, for example, list installed packages like
> this:
>
>     guix package -p /run/booted-system/profile \
>       --list-installed
>
> What doesn’t work is to operate on generations because the booted-system
> profile is a direct link to a store item; there is no indirection.  You
> also cannot use “--manifest” on it because the profile contents are
> controlled via “guix system reconfigure /path/to/config.scm”.
>
> Rather than making the differences bigger, I think we should unify
> profile management, i.e. make more of the commands for regular profiles
> work with the system profile (provided a user has root privileges).

I don't think this is a good idea. The more general purpose you make a
command the more situational the results are and the more skillful the
user has to be to use it.

As an example: You can replace matches and flame throwers with a single
tool, the flamethrower. If everybody discussing the idea is a
flamethrower operator, it probably sounds like a good idea ;-)

>> |-----------------------------------+--------------------------------|
>> | guix package --list-generations   | guix user --list-generations   |
>> | guix package --list-installed     | guix user --list-installed     |
>> | guix package --delete-generations | guix user --delete-generations |
>> | guix package --switch-generations | guix user --switch-generations |
>> | guix package --roll-back          | guix user --roll-back          |
>> | guix package --manifest           | guix user --manifest           |
>>
>> and similarly, the above ...
>>
>>>   guix package install ...
>>>   guix package remove ...
>>
>> ... would become ...
>>
>> guix user install ...
>> guix user remove ...
>
> I don’t think this is a good idea.  In addition to the reasons I stated
> above “user” is even more vague than “package” is.  The proposal to use
> “profile” for profile-related operations is a very natural one.
>
> Here at the MDC we are using many different profiles on a regular
> basis.  Multiple profiles is a common use-case.  Operating on profiles
> with “guix profile” seems really appropriate; doing this via “guix user”
> is confusing to me.  I don’t know what “user” stands for.

"user" is short for "per-user-profile", as in ...

3.1 Features
============
[...]
The ‘guix package’ command is the central tool to manage packages
(*note Invoking guix package::).  It operates on the per-user profiles,
and can be used _with normal user privileges_.

Re: Reorganizing guix package commands

[Ricardo Wurmus]

Alex Kost <alezost@gmail.com> writes:

> Here is the summary of the changes I think it would be good to have:
>
> | Replace this:                     | With this:                        |
> |-----------------------------------+-----------------------------------|
> | guix build                        | guix package build                |
> | guix edit                         | guix package definition¹          |
> | guix import                       | guix package import               |
> | guix lint                         | guix package lint                 |
> | guix refresh                      | guix package refresh              |
> | guix package --show               | guix package show                 |
> | guix package --search             | guix package search               |
> | guix package --list-available     | guix package list                 |
> |-----------------------------------+-----------------------------------|
> | 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>

This looks like a good list of changes, especially the “profile” stuff.
I’ve often written “guix profile” only to backtrack and write “package”
when my mind was set on manipulating profiles.

When operating on profiles other than the default this may look a bit
ugly:

    guix profile --profile /path/to/profile --manifest

I agree that “edit” may be confusing, and it seems that others feel that
way too, judging from the requests for help on the mailing lists and the
IRC channel.  Although “definition” isn’t pretty it is probably better
than “view” as that would collide with “show”.

~~ Ricardo

Re: Reorganizing guix package commands

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> 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

[Christopher Allan Webber]

Ludovic Courtès writes:

> Alex Kost <alezost@gmail.com> 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.

This makes sense to me.

I think it's also worth noting that this is prime ground for bikeshed[0]
territory.  So it's worth discussing and making changes, but not losing
hair over.

 - Chris

[0] http://shed.bike/

Re: Reorganizing guix package commands

[myglc2]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Kost <alezost@gmail.com> 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.

For the record, my original beef with guix edit, which seems to have
started all of this, is that, in a vanilla install, it opens an editor
on a file that the user cannot edit. So I suggested that we rename it
'guix view'.  Ironically, since then, I switched to guix git checkout,
so now I like "guix edit" just fine ;-)

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

Also these  commands would no longer clutter up 'guix help'.

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

I also like these better, see analysis below.

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

After seeing and contributing to the chaos this post generated I felt
guilty because my 'guix edit' complaint started it all.  So I made an
effort to step back and see the big picture. The table below summarizes
the Guix commands as I understand them. Columns 3 and 4 show which
commands modify user and system profiles, respectively. Columns 5, 6, 7
and 8 show commands used by different user types. Column 9 indicates
whether SUDO is required.

Table 1: command summary
========================
| column: 1        | 2                                      | 3   | 4   | 5   | 6   | 7   | 8   | 9   |
|                  |                                        | +/- | +/- | new | typ | sys |     |     |
| command          | usage                                  | usr | sys | usr | usr | adm | dev | su? |
|                  |                                        | prf | prf |     |     |     |     |     |
|------------------+----------------------------------------+-----+-----+-----+-----+-----+-----+-----+
| guix archive     | [OPTION]... PACKAGE...                 |     |     |     |     |     | x   |     |
| guix build       | [OPTION]... PACKAGE-OR-DERIVATION...   |     |     |     |     |     | x   |     |
| guix challenge   | [PACKAGE...]                           |     |     |     | x   |     | x   |     |
| guix container   | exec ARGS...                           |     |     |     |     | x   | x   |     |
| guix download    | [OPTION] URL                           |     |     |     | x   |     | x   |     |
| guix edit        | PACKAGE...                             |     |     |     | x   |     | x   |     |
| guix environment | [OPTION]... PACKAGE... [-- COMMAND...] |     |     |     | x   |     | x   |     |
| guix gc          | [OPTION]... PATHS...                   |     |     |     | x   | x   | x   |     |
| guix graph       | PACKAGE...                             |     |     |     |     |     | x   |     |
| guix hash        | [OPTION] FILE                          |     |     |     |     |     | x   |     |
| guix import      | IMPORTER ARGS ...                      |     |     |     |     |     | x   |     |
| guix lint        | [OPTION]... [PACKAGE]...               |     |     |     |     |     | x   |     |
| guix package     | --list-available[=REGEXP]              |     |     | x   | x   | x   | x   |     |
| guix package     | --install PACKAGE                      | x   |     | x   | x   |     | x   |     |
| guix package     | --upgrade PACKAGE                      | x   |     |     | x   |     | x   |     |
| guix package     | --remove PACKAGE                       | x   |     | x   | x   |     | x   |     |
| guix package     | --manifest MANIFEST                    | x   |     |     | x   |     | x   |     |
| guix package     | --list-installed[=REGEXP]              |     |     | x   | x   |     | x   |     |
| guix package     | --list-generations[=PATTERN]           |     |     |     | x   |     | x   |     |
| guix package     | --roll-back                            | x   |     | x   | x   |     | x   |     |
| guix package     | --delete-generations                   | x   |     |     | x   |     | x   |     |
| guix package     | --switch-generations                   | x   |     |     | x   |     | x   |     |
| guix package     | --search=REGEXP                        | x   |     |     | x   |     | x   |     |
| guix package     | --list-available[=REGEXP]              |     |     |     |     |     | x   |     |
| guix package     | --show=PACKAGE                         |     |     |     |     |     | X   |     |
| guix package     | [OPTION]...                            |     |     |     |     |     | x   |     |
| guix publish     | [OPTION]...                            |     |     |     |     | x   | x   | Y   |
| guix pull        | [OPTION]...                            |     |     | x   | x   | x   | x   |     |
| guix refresh     | [OPTION]... PACKAGE...                 |     |     |     |     |     | x   |     |
| guix size        | [OPTION]... PACKAGE...                 |     |     |     |     |     | x   |     |
| guix system      | [OPTION] reconfigure [FILE]            |     | x   | x   | x   | x   | x   | Y   |
| guix system      | [OPTION] list-generations [FILE]       |     |     |     | x   | x   | x   |     |
| guix system      | [OPTION] build [FILE]                  |     |     |     |     |     | x   |     |
| guix system      | [OPTION] container [FILE]              |     |     |     |     |     | x   |     |
| guix system      | [OPTION] vm [FILE]                     |     |     |     |     | x   | x   |     |
| guix system      | [OPTION] vm-image [FILE]               |     |     |     |     |     | x   |     |
| guix system      | [OPTION] disk-image [FILE]             |     |     |     |     |     | x   |     |
| guix system      | [OPTION] init [FILE]                   |     |     |     |     | x   | x   | Y   |
| guix system      | [OPTION] extension-graph [FILE]        |     |     |     |     |     | x   |     |
| guix system      | [OPTION] shepherd-graph [FILE]         |     |     |     |     |     | x   |     |


Looking at the table, my major puzzles are:

- 'guix package' specifies actions with _OPTION_ but guix system uses
  _ACTION_.

- The small set of commands (column 3) that a new user needs are
  buried. That is, 'guix help' does not show them because they are
  implemented as OPTIONs and ACTIONs. Instead it shows mostly developer
  utilities.

- guix package modifies and reports on the per-user-profile but doesn't
  actually do anything "to" packages other than show what is available.

- Several other guix commands do things "to" packages.

We could debate how to resolve these puzzles, but as you know, what I
care most about is to make Guix easier for new users.  Here are the
minimum changes that I suggest for that:

Table 2: Novice-friendly Commands
=================================
| existing command                       | new command           |
|----------------------------------------+-----------------------|
| guix package --list-available[=REGEXP] | guix available REGEXP |
| guix package --search=REGEXP           | guix find REGEXP      |
| guix package --show=PACKAGE            | guix show PACKAGE     |
| guix package --install PACKAGE         | guix install PACKAGE  |
| guix package --remove PACKAGE          | guix remove PACKAGE   |
| guix package --list-installed[=REGEXP] | guix list             |
| guix package --roll-back               | guix roll-back        |

This makes the most important new user commands simpler and it makes
them appear in "guix help". IMO, this will go a long way to improving
the novice user's experience.

- George

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

On Tue, Apr 19, 2016 at 11:45:26PM -0400, myglc2 wrote:

     Table 2: Novice-friendly Commands
     =================================
     | existing command                       | new command           |
     |----------------------------------------+-----------------------|
     | guix package --list-available[=REGEXP] | guix available REGEXP |
     | guix package --search=REGEXP           | guix find REGEXP      |
     | guix package --show=PACKAGE            | guix show PACKAGE     |
     | guix package --install PACKAGE         | guix install PACKAGE  |
     | guix package --remove PACKAGE          | guix remove PACKAGE   |
     | guix package --list-installed[=REGEXP] | guix list             |
     | guix package --roll-back               | guix roll-back        |
     
     This makes the most important new user commands simpler and it makes
     them appear in "guix help". IMO, this will go a long way to improving
     the novice user's experience.
     
I agree this would make more sense.

1. I never did understand why we use so many  -- flags.  Options are supposed
   to be just that:  Options to affect nuances about how the command should be
   executed. Eg "ls --color" (We don't type "file --list")  Options should not
   normally be used for selecting a command to run.

2. However, I wonder if such an arrangement could come back and bite us?  For
   example there are a number of other things that one might want to remove, list, show or find - 
   not just packages;  Profiles, services for example.  How would doing that fit 
   into the above scheme?

J'
     

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[Alex Kost]

John Darrington (2016-04-20 08:34 +0300) wrote:

> On Tue, Apr 19, 2016 at 11:45:26PM -0400, myglc2 wrote:
>
>      Table 2: Novice-friendly Commands
>      =================================
>      | existing command                       | new command           |
>      |----------------------------------------+-----------------------|
>      | guix package --list-available[=REGEXP] | guix available REGEXP |
>      | guix package --search=REGEXP           | guix find REGEXP      |
>      | guix package --show=PACKAGE            | guix show PACKAGE     |
>      | guix package --install PACKAGE         | guix install PACKAGE  |
>      | guix package --remove PACKAGE          | guix remove PACKAGE   |
>      | guix package --list-installed[=REGEXP] | guix list             |
>      | guix package --roll-back               | guix roll-back        |
>
>      This makes the most important new user commands simpler and it makes
>      them appear in "guix help". IMO, this will go a long way to improving
>      the novice user's experience.
>
> I agree this would make more sense.

Oh, no!  I had an opposite idea: I think there should be only
unambiguous subcommands!

> 1. I never did understand why we use so many  -- flags.  Options are supposed
>    to be just that:  Options to affect nuances about how the command should be
>    executed. Eg "ls --color" (We don't type "file --list")  Options should not
>    normally be used for selecting a command to run.

I agree, I would prefer more actions/subcommands and less options/flags.

> 2. However, I wonder if such an arrangement could come back and bite us?  For
>    example there are a number of other things that one might want to remove, list, show or find -
>    not just packages;  Profiles, services for example.  How would doing that fit
>    into the above scheme?

This is exactly why I think these commands (show, install, list, etc.)
shouldn't be top-level.  IMO some of them should be inside "guix
package" and some inside "guix profile".

-- 
Alex

Re: Reorganizing guix package commands

[myglc2]

Alex Kost <alezost@gmail.com> writes:

> John Darrington (2016-04-20 08:34 +0300) wrote:
>
>> On Tue, Apr 19, 2016 at 11:45:26PM -0400, myglc2 wrote:
>>
>>      Table 2: Novice-friendly Commands
>>      =================================
>>      | existing command                       | new command           |
>>      |----------------------------------------+-----------------------|
>>      | guix package --list-available[=REGEXP] | guix available REGEXP |
>>      | guix package --search=REGEXP           | guix find REGEXP      |
>>      | guix package --show=PACKAGE            | guix show PACKAGE     |
>>      | guix package --install PACKAGE         | guix install PACKAGE  |
>>      | guix package --remove PACKAGE          | guix remove PACKAGE   |
>>      | guix package --list-installed[=REGEXP] | guix list             |
>>      | guix package --roll-back               | guix roll-back        |
>>
>>      This makes the most important new user commands simpler and it makes
>>      them appear in "guix help". IMO, this will go a long way to improving
>>      the novice user's experience.
>>
>> I agree this would make more sense.
>
> Oh, no!  I had an opposite idea: I think there should be only
> unambiguous subcommands!
>
>> 1. I never did understand why we use so many  -- flags.  Options are supposed
>>    to be just that:  Options to affect nuances about how the command should be
>>    executed. Eg "ls --color" (We don't type "file --list")  Options should not
>>    normally be used for selecting a command to run.
>
> I agree, I would prefer more actions/subcommands and less options/flags.
>
>> 2. However, I wonder if such an arrangement could come back and bite us?  For
>>    example there are a number of other things that one might want to remove, list, show or find -
>>    not just packages;  Profiles, services for example.  How would doing that fit
>>    into the above scheme?
>
> This is exactly why I think these commands (show, install, list, etc.)
> shouldn't be top-level.  IMO some of them should be inside "guix
> package" and some inside "guix profile".

Would we all agree with the following?

IMPLIED OBJECT (guix VERB ...)
PROS:
- less typing
CONS:
- each verb must be assigned to a single object type

EXPLICIT OBJECT (guix OBJECT VERB ...)
PROS:
- verb may be (re)used on multiple object types
CONS:
- more typing

For comparison, I tried to think of similarly complex command sets. For
example, I use 'git' and 'mdadm'. They both use a mixture of these
approaches that favors the implied object model.  mdadm mostly uses
options for actions and git mostly use sub-commands. IMO, both are
difficult to use.

It is not obvious to me that they would be improved by switching to a
pure explicit object model, but it would definitely mean more
typing. Looking at git help, the commands are grouped by pattern of use.
This seems like a good thing.

Re the EXPLICIT OBJECT model:

Elsewhere in this thread, Alex cites 'ip' as an example of a pure
explicit object command set. I don't use it enough to have an opinion,
but I see that 'ip help' does not show any VERBs (AKA COMMANDS), so I
don't know how I could actually do anything reading the ip help ;-(

Any other examples?

Based on this, my opinion is:

- we should use a mixture of the models. It might not be pure but it
  is a pattern that is familiar to users

- To increase ease of use, we should assign a one-to-one relationship
  between VERB <-> OBJECT for frequently used commands.

- I still like the original proposals above

New proposal: guix help should group commands by pattern of use.

Comments?

- George

***
git help
usage: git [--version] [--help] [-C <path>] [-c name=value]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone      Clone a repository into a new directory
   init       Create an empty Git repository or reinitialize an existing one

work on the current change (see also: git help everyday)
   add        Add file contents to the index
   mv         Move or rename a file, a directory, or a symlink
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index

examine the history and state (see also: git help revisions)
   bisect     Use binary search to find the commit that introduced a bug
   grep       Print lines matching a pattern
   log        Show commit logs
   show       Show various types of objects
   status     Show the working tree status

grow, mark and tweak your common history
   branch     List, create, or delete branches
   checkout   Switch branches or restore working tree files
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   merge      Join two or more development histories together
   rebase     Forward-port local commits to the updated upstream head
   tag        Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)
   fetch      Download objects and refs from another repository
   pull       Fetch from and integrate with another repository or a local branch
   push       Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.

***
mdadm is used for building, managing, and monitoring
Linux md devices (aka RAID arrays)
Usage: mdadm --create device options...
            Create a new array from unused devices.
       mdadm --assemble device options...
            Assemble a previously created array.
       mdadm --build device options...
            Create or assemble an array without metadata.
       mdadm --manage device options...
            make changes to an existing array.
       mdadm --misc options... devices
            report on or modify various md related devices.
       mdadm --grow options device
            resize/reshape an active array
       mdadm --incremental device
            add/remove a device to/from an array as appropriate
       mdadm --monitor options...
            Monitor one or more array for significant changes.
       mdadm device options...
            Shorthand for --manage.
Any parameter that does not start with '-' is treated as a device name
or, for --examine-bitmap, a file name.
The first such name is often the name of an md device.  Subsequent
names are often names of component devices.

 For detailed help on the above major modes use --help after the mode
 e.g.
         mdadm --assemble --help
 For general help on options use
         mdadm --help-options

***
ip help
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable |
                   tunnel | tuntap | maddr | mroute | mrule | monitor | xfrm |
                   netns | l2tp | tcp_metrics | token | netconf }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -f[amily] { inet | inet6 | ipx | dnet | bridge | link } |
                    -4 | -6 | -I | -D | -B | -0 |
                    -l[oops] { maximum-addr-flush-attempts } |
                    -o[neline] | -t[imestamp] | -b[atch] [filename] |
                    -rc[vbuf] [size]}

Re: Reorganizing guix package commands

[Alex Kost]

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

> Alex Kost <alezost@gmail.com> 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

Re: Reorganizing guix package commands

[Taylan Ulrich Bayırlı/Kammer]

Alex Kost <alezost@gmail.com> writes:

> Ludovic Courtès (2016-04-19 18:52 +0300) wrote:
>
>> 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".

While I agree with the categorization, I disagree on this.  Like the
others, I would expect there to be short aliases, at least so as not to
tire users.

And maybe to help newcomers, although I think it could be more
beneficial to start teaching in terms of the categories, so users
quickly get the underlying logic, and then just offer the aliases to
reassure the users that they needn't type verbose commands all the time.


As an example of the pedagogic benefit of categorizing the commands:
many users coming from other package managers are confused as to what
exactly "installing" a package is in Guix.  It actually consists of two
steps, 1. to ensure the package is in the store (by building or
downloading), and 2. adding it to the user's profile.  But the term
"install" doesn't reflect this, and makes users think in terms of
traditional package managers where installing a package means putting
its files into /usr.  Introducing newcomers to a command like 'guix
profile add' as the primary means of adding a package to their
environment, and briefly explaining the "transparently makes sure the
package is in the store" part, would have them immediately learn one of
the basic working principles of Guix.

But maybe it's unnecessary.  I still have no strong opinion. :-)

Taylan

Re: Reorganizing guix package commands

[Ludovic Courtès]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> As an example of the pedagogic benefit of categorizing the commands:
> many users coming from other package managers are confused as to what
> exactly "installing" a package is in Guix.  It actually consists of two
> steps, 1. to ensure the package is in the store (by building or
> downloading), and 2. adding it to the user's profile.  But the term
> "install" doesn't reflect this, and makes users think in terms of
> traditional package managers where installing a package means putting
> its files into /usr.  Introducing newcomers to a command like 'guix
> profile add' as the primary means of adding a package to their
> environment, and briefly explaining the "transparently makes sure the
> package is in the store" part, would have them immediately learn one of
> the basic working principles of Guix.

Good point, I like it.  :-)

Ludo’.

Re: Reorganizing guix package commands

[myglc2]

ludo@gnu.org (Ludovic Courtès) writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> As an example of the pedagogic benefit of categorizing the commands:
>> many users coming from other package managers are confused as to what
>> exactly "installing" a package is in Guix.  It actually consists of two
>> steps, 1. to ensure the package is in the store (by building or
>> downloading), and 2. adding it to the user's profile.  But the term
>> "install" doesn't reflect this, and makes users think in terms of
>> traditional package managers where installing a package means putting
>> its files into /usr.  Introducing newcomers to a command like 'guix
>> profile add' as the primary means of adding a package to their
>> environment, and briefly explaining the "transparently makes sure the
>> package is in the store" part, would have them immediately learn one of
>> the basic working principles of Guix.
>
> Good point, I like it.  :-)
>
> Ludo’.

Yes, we should help newcomers delve into Guix.

But a strangely named install instruction is not an effective way to
accomplish this. We should find a better way.

How about an animation of the processes you describe on the status line?

Then a newcomer can learn while waiting for the software to install :-)

The best way to make it easy for newcomers to see this animation is to
give them what they expect -- an instruction named 'guix install'.

Re: Reorganizing guix package commands

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Wed, Apr 20, 2016 at 11:46:20AM +0200, Taylan Ulrich Bay??rl??/Kammer wrote:
     
     As an example of the pedagogic benefit of categorizing the commands:
     many users coming from other package managers are confused as to what
     exactly "installing" a package is in Guix.  It actually consists of two
     steps, 1. to ensure the package is in the store (by building or
     downloading), and 2. adding it to the user's profile.  But the term
     "install" doesn't reflect this, and makes users think in terms of
     traditional package managers where installing a package means putting
     its files into /usr.  Introducing newcomers to a command like 'guix
     profile add' as the primary means of adding a package to their
     environment, and briefly explaining the "transparently makes sure the
     package is in the store" part, would have them immediately learn one of
     the basic working principles of Guix.
     

I think the last part of your suggestion is what is really important - 
     * explaining to the user what is going on *    

This is something where I think we can do better.

However if "guix profile add" adds a package to a user's profile,
what does "guix profile rm" do?   Does it remove  a package from the
profile, or does it remove the profile?

J'




-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Reorganizing guix package commands

[Taylan Ulrich Bayırlı/Kammer]

ludo@gnu.org (Ludovic Courtès) writes:

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

I'd like to re-propose the use of '--' to delineate the end of arguments
to a sub-command.  E.g.:

  guix install foo bar -- remove baz bat

(Leaving aside whether it's 'guix install', 'guix package install',
'guix profile add', or anything else.)

Taylan

Re: Reorganizing guix package commands

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

On Wed, Apr 20, 2016 at 11:29:25AM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> 
> >> 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?
> 
> I'd like to re-propose the use of '--' to delineate the end of arguments
> to a sub-command.  E.g.:
> 
>   guix install foo bar -- remove baz bat
> 
> (Leaving aside whether it's 'guix install', 'guix package install',
> 'guix profile add', or anything else.)
> 
> Taylan
> 

Currently you can already call

    guix package -i foo bar -r baz

and it'll install and remove packages as you'd expect. Another option
that'll cut down on the length of the command but keep it obvious what's
going on is if it were changed to

    guix profile +foo +bar -baz

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Reorganizing guix package commands

[Taylan Ulrich Bayırlı/Kammer]

Efraim Flashner <efraim@flashner.co.il> writes:

> On Wed, Apr 20, 2016 at 11:29:25AM +0200, Taylan Ulrich Bayırlı/Kammer wrote:
>> ludo@gnu.org (Ludovic Courtès) writes:
>> 
>> >> 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?
>> 
>> I'd like to re-propose the use of '--' to delineate the end of arguments
>> to a sub-command.  E.g.:
>> 
>>   guix install foo bar -- remove baz bat
>> 
>> (Leaving aside whether it's 'guix install', 'guix package install',
>> 'guix profile add', or anything else.)
>> 
>> Taylan
>> 
>
> Currently you can already call
>
>     guix package -i foo bar -r baz

Right, that works when install/remove are switches.  My proposal was
meant in the context of making them sub-commands instead of switches.

Taylan

Re: Reorganizing guix package commands

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Am 18.04.2016 um 10:57 schrieb Alex Kost:
> In general, I think it would be good to move package commands inside
> "guix package", e.g, to make "guix package lint", "guix package size",
> etc.

When changing this, we could also think about making "options" into real
sub-commands, eg.
"guix package --install" into "guix package install". (Same for
uninstall/remove, upgrade(?), list-generations, etc.)

This would meed Ludo's idea of making "package" the default.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/bewertung-pgp-verschlusselung-bei-web.de-und-gmx

Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung


[-- Attachment #2: Type: text/html, Size: 2042 bytes --]