Neonira,
On Fri, Aug 9, 2019 at 12:27 PM neonira Arinoem <neon...@gmail.com> wrote:
> I do not follow you Gabriel. Package name must not use digit numbers.
> Tarbal will use them, taken from the DESCRIPTION file, version field.
>
I was referring to Jim Hester's original proposal, which AFAIU was just to
add "_" to the allowed characters. Yours goes much farther an also adds
dash but removes all numbers (which I admit I didn't notice) and upper case
letters. This is a much more radical change, and one I don't really
understand the justification for. I get forcing lowercase (Id rather the
machinery were just case insensitive, myself) but disallowing numbers,
given that one of the most popular contributed packages of all time -
ggplot2 - has a number in it, seems strange. I also don't really grok the
desire for dashes on top of periods and underscores.
Best,
~G
> That's why I consider the weird case name you presented as irrelevant, and
> not to be considered.
>
>
> Le ven. 9 août 2019 à 20:41, Gabriel Becker <gabembec...@gmail.com> a
> écrit :
>
>>
>>
>> On Fri, Aug 9, 2019 at 11:05 AM neonira Arinoem <neon...@gmail.com>
>> wrote:
>>
>>> Won't it be better to have a convention that allows lowercase, dash,
>>> underscore and dot as only valid characters for new package names and
>>> keep
>>> the ancient format validation scheme for older package names?
>>>
>>
>> Validation isn't the only thing we need to do wrt package names. we also
>> need to detect them, and particularly, in at least one case, extract them
>> from package tarball filenames (which we also need to be able to
>> detect/find).
>>
>> If we were writing a new language and people wanted to allow snake case
>> in package names, sure, but we're talking about about changing how a small
>> but package names and package tarballs have always (or at least a very long
>> time, I didn't check) had the same form, and it seems expressive enough to
>> me? I mean periods are allowed if you feel a strong need for something
>> other than a letter.
>>
>> 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?
>>
>>
>>
>> For the record @Ben Bolker <bbol...@gmail.com>
>>
>> Packages that mix case anywhere in their package name:
>>
>> > table(grepl("((^[a-z].*[A-Z])|(^[A-Z].*[a-z]))", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 8818 5932
>>
>>
>> Packages which start with lower case and have at least one upper
>>
>> > table(grepl("((^[a-z].*[A-Z]))", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 12315 2435
>>
>>
>> Packages which start with uppercase and have at least one lower
>>
>> > table(grepl("((^[A-Z].*[a-z]))", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 11253 3497
>>
>> Packages which take advantage of the above-mentioned legality of periods
>>
>> > table(grepl(".", row.names(a1), fixed=TRUE))
>>
>>
>> FALSE TRUE
>>
>> 14259 491
>>
>> Packages with pure lower-case alphabetic names
>>
>> > table(grepl("^[a-z]+$", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 7712 7038
>>
>>
>> Packages with pure upper-case alphabetic names
>>
>> > table(grepl("^[A-Z]+$", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 13636 1114
>>
>>
>> Package with at least one numeric digit in their name
>>
>> > table(grepl("[0-9]", row.names(a1)))
>>
>>
>> FALSE TRUE
>>
>> 14208 542
>>
>>
>> It would be interesting to do an actual analysis of the changes in these
>> trends over time, but I Really should be working, so that will have to
>> either wait or be done by someone else.
>> Best,
>> ~G
>>
>>
>>
>>> This could be implemented by a single function, taking a strictNaming_b_1
>>> parameter which defaults to true. Easy to use, and compliance results
>>> will
>>> vary according to the parameter value, allowing strict compliance for new
>>> package names and lazy compliance for older ones.
>>>
>>> Doing so allows to enforce a new package name convention while also
>>> insuring continuity of compliance for already existing package names.
>>>
>>> Fabien GELINEAU alias Neonira
>>>
>>> Le ven. 9 août 2019 à 18:40, Kevin Wright <kw.s...@gmail.com> a écrit :
>>>
>>> > Please, no. I'd also like to disallow uppercase letters in package
>>> names.
>>> > For instance, the cuteness of using a capital "R" in package names is
>>> > outweighed by the annoyance of trying to remember which packages use an
>>> > upper-case letter.
>>> >
>>> > On Thu, Aug 8, 2019 at 9:32 AM Jim Hester <james.f.hes...@gmail.com>
>>> > wrote:
>>> >
>>> > > Are there technical reasons that package names cannot be snake case?
>>> > > This seems to be enforced by `.standard_regexps()$valid_package_name`
>>> > > which currently returns
>>> > >
>>> > > "[[:alpha:]][[:alnum:].]*[[:alnum:]]"
>>> > >
>>> > > Is there any technical reason this couldn't be altered to accept `_`
>>> > > as well, e.g.
>>> > >
>>> > > "[[:alpha:]][[:alnum:]._]*[[:alnum:]]"
>>> > >
>>> > > I realize that historically `_` has not always been valid in variable
>>> > > names, but this has now been acceptable for 15+ years (since R 1.9.0
>>> I
>>> > > believe). Might we also allow underscores for package names?
>>> > >
>>> > > Jim
>>> > >
>>> > > ______________________________________________
>>> > > R-devel@r-project.org mailing list
>>> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>>> > >
>>> >
>>> >
>>> > --
>>> > Kevin Wright
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > ______________________________________________
>>> > R-devel@r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
