Underscores in package names

I do not follow you Gabriel. Package name must not use digit numbers.
Tarbal will use them, taken from the DESCRIPTION file, version field.

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 <gabembecker at gmail.com> a
?crit :

On Fri, Aug 9, 2019 at 11:05 AM neonira Arinoem <neonira at 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 <bbolker at 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.stat at 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.hester at 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

--
Kevin Wright

        [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]