[Rd] Underscores in package names
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Wed Aug 14 11:16:11 CEST 2019
>>>>> Duncan Murdoch
>>>>> on Fri, 9 Aug 2019 20:23:28 -0400 writes:
> On 09/08/2019 4:37 p.m., Gabriel Becker wrote:
>> On Fri, Aug 9, 2019 at 1:17 PM Duncan Murdoch <murdoch.duncan using gmail.com
>> <mailto:murdoch.duncan using gmail.com>> wrote:
>> On 09/08/2019 2:41 p.m., Gabriel Becker wrote:
>> > Note that this proposal would make mypackage_2.3.1 a valid
>> *package name*,
>> > whose corresponding tarball name might be mypackage_2.3.1_2.3.2
>> after a
>> > patch. Yes its a silly example, but why allow that kind of ambiguity?
>> CRAN already has a package named "FuzzyNumbers.Ext.2", whose tarball is
>> FuzzyNumbers.Ext.2_3.2.tar.gz, so I think we've already lost that game.
>> I suppose technically 2 is a valid version number for a package (?) so I
>> suppose you have me there. But as Ben pointed out while I was writing
>> this, all I can really say is that in practice they read to me (as
>> someone who has administered R on a large cluster and written
>> build-system software for it) as substantially different levels of
>> ambiguity. I do acknowledge, as Ben does, that yes a more complex
>> regular expression/splitting algorithm can be written that would handle
>> the more general package names. I just don't personally see a motivation
>> that justifies changing something this fundamental (even if it is both
>> narrow and was initially more or less arbitrarily chosen) about R at
>> this late date.
>> I guess at the end of the day, I guess what I'm saying is that breaking
>> and changing things is sometimes good, but if we're going to rock the
>> boat personally I'd want to do so going after bigger wins than this one.
>> Thats just my opinion though.
> Sorry, I wasn't clear. I agree with you. I was just saying that the
> particular argument based on ugly tarball names isn't the reason.
> Duncan Murdoch
Thank you (and Gabe).
We have had some R core internal "talk" about Jim Hester's
suggestion (of adding underscores to the allow characters in
Duncan had already given a good reason why such a change would be problematic
(the underscore being used as unique separator of package name
and version in source and binary package archives),
and with Jim's offer to find and provide patches for all places
this is used in the R sources, we've convinced ourselves that
there is much more code "out there", notably 'devops' code in
scripts, which currently relies on the current package naming
rules and which could break, often only rarely and hence
possibly unnoticed for too long.
Also, we've not seen compelling arguments why the current scheme
would be too limited (people mentioned that if you must use a
separator, "." was available).
Consequence: We stay with the stability principle and the
package naming scheme is _not_ going to be changed for now.
ETH Zurich and R Core Team
More information about the R-devel