unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex Kost <alezost@gmail.com>
To: John Darrington <john@darrington.wattle.id.au>
Cc: guix-devel@gnu.org, myglc2 <myglc2@gmail.com>
Subject: Re: Reorganizing guix package commands
Date: Wed, 20 Apr 2016 11:52:47 +0300	[thread overview]
Message-ID: <8760vc7jc0.fsf@gmail.com> (raw)
In-Reply-To: <20160420053425.GA3233@jocasta.intra> (John Darrington's message of "Wed, 20 Apr 2016 07:34:25 +0200")

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

  reply	other threads:[~2016-04-20  8:52 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18  8:57 Reorganizing guix package commands Alex Kost
2016-04-18 16:10 ` John Darrington
2016-04-19  8:01   ` Alex Kost
2016-04-18 17:20 ` Ludovic Courtès
2016-04-18 21:50   ` myglc2
2016-04-19  5:17     ` John Darrington
2016-04-19 12:57       ` myglc2
2016-04-19 13:03         ` Thompson, David
2016-04-19 13:35           ` John Darrington
2016-04-19 13:51           ` myglc2
2016-04-19 15:24       ` Ludovic Courtès
2016-04-19 10:47     ` Alex Kost
2016-04-19 10:58       ` Ricardo Wurmus
2016-04-19 12:45       ` myglc2
2016-04-19  7:52   ` Alex Kost
2016-04-19  9:17     ` Taylan Ulrich Bayırlı/Kammer
2016-04-19 10:37       ` Alex Kost
2016-04-19  9:23     ` Hartmut Goebel
2016-04-19 10:16       ` Alex Kost
2016-04-19 14:39       ` John Darrington
2016-04-19 13:00     ` myglc2
2016-04-19 13:43       ` Ricardo Wurmus
2016-04-19 14:29         ` myglc2
2016-04-19 13:55     ` Ricardo Wurmus
2016-04-19 15:52     ` Ludovic Courtès
2016-04-19 19:56       ` Christopher Allan Webber
2016-04-20  3:45       ` myglc2
2016-04-20  5:34         ` John Darrington
2016-04-20  8:52           ` Alex Kost [this message]
2016-04-20 17:05             ` myglc2
2016-04-20  8:29       ` Alex Kost
2016-04-20  9:46         ` Taylan Ulrich Bayırlı/Kammer
2016-04-20 21:45           ` Ludovic Courtès
2016-04-21 12:34             ` myglc2
2016-04-21  5:20           ` John Darrington
2016-04-20  9:29       ` Taylan Ulrich Bayırlı/Kammer
2016-04-21  2:49         ` Efraim Flashner
2016-04-21  7:10           ` Taylan Ulrich Bayırlı/Kammer
2016-04-18 21:13 ` Hartmut Goebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8760vc7jc0.fsf@gmail.com \
    --to=alezost@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=john@darrington.wattle.id.au \
    --cc=myglc2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).