On 09/08/2019 4:37 p.m., Gabriel Becker wrote:
Duncan,
On Fri, Aug 9, 2019 at 1:17 PM Duncan Murdoch <murdoch.dun...@gmail.com
<mailto:murdoch.dun...@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
