guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add guix install command


From: Chris Marusich
Subject: Re: Add guix install command
Date: Fri, 07 Aug 2015 16:52:20 +0000

Hi,

As a new user myself, I think I'd like to add my own opinion.

When the subcommands are explicitly namespaced (as in "guix package -i foo"), I find it easier to (1) understand and (2) look up usage information. In my opinion, shoving many disparate actions (and thus, options) into a single global namespace complicates matters greatly. It puts more cognitive burden on the user. If you do that, then users have to remember whether the word that comes after "guix" is a full-fledged subcommand, or just a shortcut into one (and they also have to remember whether there are any differences or limitations when using one versus the other). If you really want a short alias for "guix package --install", you can always create one yourself in exactly the way you want using a shell alias, a shell function, or a wrapper script. It doesn't seem necessary, to me, to complicate usage by adding alternative invocations by default. It id better to provide a simple default and let the users customize it if they want to.

In addition, I also think that an invocation like "guix install" would be suboptimal because it wouldn't be immediately clear whether the invocation will install packages or modify the system itself (like "guix system reconfigure foo"). This is an example of how removing the namespacing might complicate things.

You've mentioned apt and suggested that it does this the right way (apt-get install pkg). I respectfully disagree. I think that, from a user perspective, it's cleaner to have subcommands than it is to have one command for installing (apt-get) and another for searching (apt-cache). With apt, it may seem like you are invoking a single command, but you have to remember which apt tool to use, which in the end isn't much different than the way guix does it. But I'm glad guix uses subcommands instead of separate commands, since I think that's cleaner, easier to remember, and easier to look up information about.

I think keeping things simple makes a lot of sense, especially since you can add your own convenience wrapper easily using shell aliases etc. Thanks for listening to my opinion - Guix is great and I'm looking forward to using it more and more!

Thank you,
Chris


On Fri, Aug 7, 2015, 05:36 Andy Wingo <address@hidden> wrote:
Thanks for the comments.  Just a couple points, happy to wait for
Ludovic to get back.

On Fri 07 Aug 2015 14:22, "Thompson, David" <address@hidden> writes:

>> In the case of "guix install", yes.  However what would you show for
>> "guix install --help"?  What would error messages show: "guix package"
>> or "guix install"?  Would the user perceive it as a separate command or
>> would the fact that it is an alias be visible to the user?
>
> If we were to go the aliasing route, we could still make the --help
> and --version flags show 'guix install' with a simple pattern match on
> the arguments list.

You would have to modify the set of arguments as well.  What it mean to
say e.g. "guix install --remove foo bar" ?  If it were supported as an
alias and all guix package options were there, "guix package --remove
foo bar" would remove foo and bar, but you might expect "guix install
--remove foo bar" to remove foo but install bar -- but even then "guix
install --remove" is nonsensical.

To me I see the advantage of guix install as "paving the cowpaths" --
making a common use case easy while still pointing to more powerful
tools.

> every other tool encapsulates it's full functionality under a single
> subcommand: import, system, environment, gc, lint, etc.

This is a very slight advantage from the maintainer POV but from the
user's POV it's a negative thing, I think.

"guix package" just does too much: for example try "guix package
--install foo --list-available".  It doesn't install foo at all, or even
try!

Andy


reply via email to

[Prev in Thread] Current Thread [Next in Thread]