From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kost Subject: Re: 02/02: gnu: Add s. Date: Wed, 07 Jun 2017 12:29:10 +0300 Message-ID: <87y3t487tl.fsf@gmail.com> References: <20170604144555.7655.18380@vcs0.savannah.gnu.org> <20170604144556.5AFA1206F7@vcs0.savannah.gnu.org> <878tl770ht.fsf@netris.org> <87zidl9ew5.fsf@gmail.com> <87shjcyhax.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dIXHD-0001dP-3z for guix-devel@gnu.org; Wed, 07 Jun 2017 05:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dIXH8-0002o8-6K for guix-devel@gnu.org; Wed, 07 Jun 2017 05:29:19 -0400 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:33685) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dIXH7-0002m3-Ue for guix-devel@gnu.org; Wed, 07 Jun 2017 05:29:14 -0400 Received: by mail-lf0-x232.google.com with SMTP id a136so3259441lfa.0 for ; Wed, 07 Jun 2017 02:29:10 -0700 (PDT) In-Reply-To: <87shjcyhax.fsf@netris.org> (Mark H. Weaver's message of "Tue, 06 Jun 2017 16:47:34 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver (2017-06-06 16:47 -0400) wrote: > Alex Kost 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 comm= it 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 =E2=80= =93 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 > renamed. > > 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? Thanks for this descriptive answer! Now I understand your position and I agree with it :-) BTW, I've just recalled that there are "s" and "f" emacs packages (we named them "emacs-s" and "emacs-f", of course). --=20 Alex