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 >> > > >> > > ______________________________________________ >> > > R-devel at r-project.org mailing list >> > > https://stat.ethz.ch/mailman/listinfo/r-devel >> > > >> > >> > >> > -- >> > Kevin Wright >> > >> > [[alternative HTML version deleted]] >> > >> > ______________________________________________ >> > R-devel at r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >[[alternative HTML version deleted]]
On 2019-08-09 14:27, neonira Arinoem 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. > > That's why I consider the weird case name you presented as irrelevant, > and > not to be considered.ggplot2 ? Numbers are allowed in package names right now.> 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 >>> > > >>> > > ______________________________________________ >>> > > R-devel at r-project.org mailing list >>> > > https://stat.ethz.ch/mailman/listinfo/r-devel >>> > > >>> > >>> > >>> > -- >>> > Kevin Wright >>> > >>> > [[alternative HTML version deleted]] >>> > >>> > ______________________________________________ >>> > R-devel at r-project.org mailing list >>> > https://stat.ethz.ch/mailman/listinfo/r-devel >>> > >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel-- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock
Neonira, On Fri, Aug 9, 2019 at 12:27 PM neonira Arinoem <neonira at 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 <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 >>> > > >>> > > ______________________________________________ >>> > > R-devel at r-project.org mailing list >>> > > https://stat.ethz.ch/mailman/listinfo/r-devel >>> > > >>> > >>> > >>> > -- >>> > Kevin Wright >>> > >>> > [[alternative HTML version deleted]] >>> > >>> > ______________________________________________ >>> > R-devel at r-project.org mailing list >>> > https://stat.ethz.ch/mailman/listinfo/r-devel >>> > >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>[[alternative HTML version deleted]]
Yes Brian. That's currently possible. I am not speaking of what is currently possible but of the rules we should enforce, using both strict compliance for new rules and lazy compliance for older packages Le ven. 9 ao?t 2019 ? 21:35, Brian G. Peterson <brian at braverock.com> a ?crit :> On 2019-08-09 14:27, neonira Arinoem 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. > > > > That's why I consider the weird case name you presented as irrelevant, > > and > > not to be considered. > > ggplot2 ? > > Numbers are allowed in package names right now. > > > > 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 > >>> > > > >>> > > ______________________________________________ > >>> > > R-devel at r-project.org mailing list > >>> > > https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > > > >>> > > >>> > > >>> > -- > >>> > Kevin Wright > >>> > > >>> > [[alternative HTML version deleted]] > >>> > > >>> > ______________________________________________ > >>> > R-devel at r-project.org mailing list > >>> > https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> ______________________________________________ > >>> R-devel at r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock >[[alternative HTML version deleted]]