unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Inconsistencies in 'guix system' and 'guix package'
@ 2015-10-27 14:27 Alex Kost
  2015-10-27 16:06 ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Kost @ 2015-10-27 14:27 UTC (permalink / raw)
  To: guix-devel

Hello,

1. Should 'guix system' actions share the same options?

I think it is confusing that recently added 'guix system' actions
(dmd-graph, extension-graph and list-generations) can take the same
command-line options as the other system actions (--dry-run, --no-grub,
etc.), because specifying these options doesn't take any effect.

Another thing: "guix system <any-action> --help" displays the same help
message for any action.  With 'list-generations' it is even more
confusing, as (unlike the other actions) it takes PATTERN, not FILE as
the positional argument.

What about splitting 'guix system' into submodules (as it is done for
'guix import') with putting general bits into (guix scripts system)?

2. What about adding subcommands for 'guix package'?

As we have 'guix system list-generations', would it be more consistent
to have 'guix package list-generations' instead of the current 'guix
package --list-generations'?

More generally, I think there is a similar issue with 'guix package', as
with 'guix system': using some options together doesn't make sense
(e.g., using --keep-failed, --show and --dry-run).  For example, the
following command:

  guix package --show=magit --list-generations=1

displays generation 1, while the following:

  guix package --list-generations=1 --show=magit

describes 'magit' package.

Analogously, would it be appropriate to replace some 'guix package'
options (--show, --list-generations --list-installed, --list-available)
with subcommands ('guix package show', ...)?

I'm not talking about adding 'guix install' or alike as was discussed in
a separate thread¹, but I agree with Andy that «"guix package" is doing
too much as it is».

¹ http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00086.html

-- 
Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Inconsistencies in 'guix system' and 'guix package'
  2015-10-27 14:27 Inconsistencies in 'guix system' and 'guix package' Alex Kost
@ 2015-10-27 16:06 ` Ludovic Courtès
  2015-10-28 21:36   ` Alex Kost
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2015-10-27 16:06 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel

Alex Kost <alezost@gmail.com> skribis:

> 1. Should 'guix system' actions share the same options?
>
> I think it is confusing that recently added 'guix system' actions
> (dmd-graph, extension-graph and list-generations) can take the same
> command-line options as the other system actions (--dry-run, --no-grub,
> etc.), because specifying these options doesn't take any effect.
>
> Another thing: "guix system <any-action> --help" displays the same help
> message for any action.  With 'list-generations' it is even more
> confusing, as (unlike the other actions) it takes PATTERN, not FILE as
> the positional argument.
>
> What about splitting 'guix system' into submodules (as it is done for
> 'guix import') with putting general bits into (guix scripts system)?

I like the idea of submodules à la ‘guix import’!  Would you like to
give it a try?  The thing is, all the actions except ‘list-generations’
have a lot in common.

I am indeed unsatisfied with the current situation, but did not have a
better idea.

> 2. What about adding subcommands for 'guix package'?
>
> As we have 'guix system list-generations', would it be more consistent
> to have 'guix package list-generations' instead of the current 'guix
> package --list-generations'?

Or the other way around?  :-)

> More generally, I think there is a similar issue with 'guix package', as
> with 'guix system': using some options together doesn't make sense
> (e.g., using --keep-failed, --show and --dry-run).  For example, the
> following command:
>
>   guix package --show=magit --list-generations=1
>
> displays generation 1, while the following:
>
>   guix package --list-generations=1 --show=magit
>
> describes 'magit' package.
>
> Analogously, would it be appropriate to replace some 'guix package'
> options (--show, --list-generations --list-installed, --list-available)
> with subcommands ('guix package show', ...)?

But then some operations would have no subcommands: install, remove,
rollback, etc.  So the syntax would be:

  guix package SUBCOMMAND OPTIONS

or:

  guix package OPTIONS

depending on the situation.  That’s not great either.

Maybe (thinking out loud) we could separate this in:

  guix package -> for installation, removal, upgrade, rollback
  guix query   -> for list-whatever, show

and then we need to find a place for --delete-generations.

Thoughts?

Seems like a can of worms, definitely post-0.9.0.

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Inconsistencies in 'guix system' and 'guix package'
  2015-10-27 16:06 ` Ludovic Courtès
@ 2015-10-28 21:36   ` Alex Kost
  0 siblings, 0 replies; 3+ messages in thread
From: Alex Kost @ 2015-10-28 21:36 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès (2015-10-27 19:06 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> 1. Should 'guix system' actions share the same options?
>>
>> I think it is confusing that recently added 'guix system' actions
>> (dmd-graph, extension-graph and list-generations) can take the same
>> command-line options as the other system actions (--dry-run, --no-grub,
>> etc.), because specifying these options doesn't take any effect.
>>
>> Another thing: "guix system <any-action> --help" displays the same help
>> message for any action.  With 'list-generations' it is even more
>> confusing, as (unlike the other actions) it takes PATTERN, not FILE as
>> the positional argument.
>>
>> What about splitting 'guix system' into submodules (as it is done for
>> 'guix import') with putting general bits into (guix scripts system)?
>
> I like the idea of submodules à la ‘guix import’!  Would you like to
> give it a try?  The thing is, all the actions except ‘list-generations’
> have a lot in common.

Yes, I would like to give a try, though I will not give a time to it
very soon :-(  But sooner or later… I hope :-)

[...]
>> Analogously, would it be appropriate to replace some 'guix package'
>> options (--show, --list-generations --list-installed, --list-available)
>> with subcommands ('guix package show', ...)?
>
> But then some operations would have no subcommands: install, remove,
> rollback, etc.  So the syntax would be:
>
>   guix package SUBCOMMAND OPTIONS
>
> or:
>
>   guix package OPTIONS
>
> depending on the situation.  That’s not great either.

Heh, not great, I agree.

> Maybe (thinking out loud) we could separate this in:
>
>   guix package -> for installation, removal, upgrade, rollback
>   guix query   -> for list-whatever, show
>
> and then we need to find a place for --delete-generations.
>
> Thoughts?

'guix query' sounds interesting!

> Seems like a can of worms, definitely post-0.9.0.

Indeed; I just feel there are things to improve there, so I raised this
question.  But I should probably say "Sorry for bothering", as I don't
really have my understanding how an ideal 'guix package' should look.

Thanks for answering!  (and sorry for bothering)

-- 
Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-10-28 21:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-27 14:27 Inconsistencies in 'guix system' and 'guix package' Alex Kost
2015-10-27 16:06 ` Ludovic Courtès
2015-10-28 21:36   ` Alex Kost

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).