search for: strictnaming_b_1

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? 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 complian...

...> 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 conventio...

...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? > > 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 > i...

....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 > in...

...he 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...

...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? > > > > 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...

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