[Top][All Lists]

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

Re: 02/02: gnu: Add s.

From: Mark H Weaver
Subject: Re: 02/02: gnu: Add s.
Date: Tue, 06 Jun 2017 16:47:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Alex Kost <address@hidden> writes:

> Mark H Weaver (2017-06-04 20:15 -0400) wrote:
>>> +(define-public s
>>> +  (let ((commit "6604341edb3a775ff94415762af3ee9bd86bfb3c")
>>> +        (revision "1"))
>>> +    (package
>>> +      (name "s")
>>> +      (version (string-append "0.0.0-" revision "." (string-take commit 
>>> 7)))
>> I think we should rename this package and variable name to 's-shell' or
>> something along those lines.  's' is commonly used as a local variable
>> name.  Single character variable names are in short supply, and I don't
>> think we should allocate them to packages.
>> Thoughts?
> And what about "r" package?

Ah, I had forgotten about 'r'.  Thanks for reminding me :)

I think we can make an exception for a package as firmly established and
widely used as 'r'.  It's already been in Guix for a long time, and
there are hundreds of packages based on it.

However, 's' has not yet had any releases, and as with any highly
experimental new program, chances are quite slim that it will ever gain
a non-trivial number of users.  That's nothing personal, it's just a
simple fact about new projects: the overwhelming majority of new
projects never gain traction.

Do we really want to permanently allocate to it one of the 25 remaining
lowercase ASCII single-letter names?  That's prime real-estate in the
space of possible names.  Frankly, I think it's hubris for someone to
claim one of those names for their experimental new project.  Do we want
to set a precedent that anyone can grab one of those single-character
names for their pet project, regardless of whether it has any users
besides its author?

> In my opinion, package names for "r" and "s" should stay the same – I
> think these names are expected by users.  As for the variable names,
> they may be renamed, if it is needed.

I can understand that point of view.  Recently, someone named their new
package 'ao'.  We simply weren't able to give it that name in Guix,
because we already have a package named 'ao' in Guix.

If only 26 people in the entire world choose to give their project a
two-letter name, then the chances are good that there will be a
collision (c.f. birthday paradox), and one of them will need to be

Likewise, if only 5 people in the world choose a single-letter name,
then chances are good that there will be a collision.  Who here has the
hubris to choose one of those names?  Do we want to enable that?


reply via email to

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