all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Reorganizing guix package commands
Date: Wed, 20 Apr 2016 11:46:20 +0200	[thread overview]
Message-ID: <87shyg4npv.fsf@T420.taylan> (raw)
In-Reply-To: <87a8ko7keg.fsf@gmail.com> (Alex Kost's message of "Wed, 20 Apr 2016 11:29:43 +0300")

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

  reply	other threads:[~2016-04-20  9:46 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
2016-04-20 17:05             ` myglc2
2016-04-20  8:29       ` Alex Kost
2016-04-20  9:46         ` Taylan Ulrich Bayırlı/Kammer [this message]
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

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

  git send-email \
    --in-reply-to=87shyg4npv.fsf@T420.taylan \
    --to=taylanbayirli@gmail.com \
    --cc=alezost@gmail.com \
    --cc=guix-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.