On 06/03/2024 1:00 p.m., Martin Maechler wrote:
Richard M Heiberger on Wed, 6 Mar 2024 17:10:50 +0000 writes:> Thank you, I will do that reversion in a few days. (good; I'm sorry I did not see this, before I replied to Joshua's) > Before I do, I want to ask if the default export generated by R CMD build should be changed. > the default is exportPattern("."), which seems to be the cause of the problem. > Might the default be changed to exportPattern("^[^\\.]") ? That's a good suggestion in my view.
One thing I don't understand about that suggestion (which is taken from WRE, I'm not blaming Rich for it): why include the backslash in the negated character class? Does R ever create variables starting with a backslash, or is this just a more or less harmless error, thinking that the dot needs escaping?
Duncan Murdoch
That default *was* sensible when namespaces were introduced (~ 2004?): It did indeed ensure that the package worked entirely as before there were namespaces -- always everything was "exported", i.e. publicly visible and part of the implicit package API. And such 100%-backcompatibility was of course sensible to ease transition. But we are ca. 20 years later now, and I guess that most active R users (incl package developers) either don't know or then hardly remember that R had no namespaces originally. I see it only in the tools pkg hidden writeDefaultNamespace() which is used only once in tools:::.build_packages() ## add NAMESPACE if the author didn't write one if(!file.exists(namespace <- file.path(pkgname, "NAMESPACE")) ) { messageLog(Log, "creating default NAMESPACE file") writeDefaultNamespace(namespace) } Note that the "Bible" on R packages has always been 'Writing R Extensions' - in the R sources, doc/manual/R-exts.texi It has -- *since* svn rev 23392, 003-02-27 19:02:45 +0100 by Luke Tierney and commit message "Added name space support for packages that do not use methods." the text, e.g., at https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exportsFor packages with many variables to export it may be more convenient to specify the names to export with a regular expression using ‘exportPattern’. The directiveexportPattern("^[^\\.]")exports all variables that do not start with a period. However, such broad patterns are not recommended for production code: it is better to list all exports or use narrowly-defined groups. .....so I agree we should change the default. The R code above shows that the user does get a message about automatic NAMESPACE creation. If there are cases, where people need to export even .<some>, they should have to consciously choose so. Martin >> On Mar 6, 2024, at 11:57, Joshua Ulrich <josh.m.ulr...@gmail.com> wrote: >> >> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger <r...@temple.edu> wrote: >>> >>> Thank you Duncan, Jeff, Ivan. >>> >>> I did all that Duncan and Jeff suggested, plus a bit more that appeared to be necessary. >>> All of what I did is documented in the RcmdrPlugin.HH/NEWS file. >>> >>> Ivan's comments were received after I sent 1.1-50 to CRAN and it was accepted. >>> >> I recommend you revert all the changes you made that are documented in >> the package NEWS, and at minimum follow Ivan's advice to use >> exportPattern("^[^\\.]") instead of exportPattern("."). It would be >> even better to follow the advice in Writing R Extensions and list each >> exported object individually. >> >>> I suggest that my notes in the NEWS file, perhaps augmented with Ivan's comments, >>> might be added to utils/man/globalVariables.Rd and to the >>> " >>> section ‘Package >>> structure’ in the ‘Writing R Extensions’ manual. >>> " >>> >> That section of Writing R Extensions specifically says not to do what you did. >> >> Beware of patterns which include names starting with a period: some >> of these are internal-only variables and should never be exported, >> e.g. ‘.__S3MethodsTable__.’ (and loading excludes known cases). >> >> Duncan pointed out that '.__global__' is an internal-only variable >> created by globalVariables(), which means it should never be exported >> by a package. Imagine the number of conflicts there would be if every >> package that used globalVariables() exported the '.__global__' >> object... there would probably be thousands, yikes! >> >> It's possible that future versions of 'R CMD check' will error if >> there are any incorrectly exported internal variables (like >> '.__global__'), which would cause your package to fail. >> >> Best, >> Josh >> >> >>> >>>> On Mar 6, 2024, at 01:38, Ivan Krylov <ikry...@disroot.org> wrote: >>>> >>>> В Tue, 5 Mar 2024 22:41:32 +0000 >>>> "Richard M. Heiberger" <r...@temple.edu> пишет: >>>> >>>>> Undocumented code objects: >>>>> '.__global__' >>>>> All user-level objects in a package should have documentation >>>>> entries. See chapter 'Writing R documentation files' in the 'Writing R >>>>> Extensions' manual. >>>> >>>> This object is not here for the user of the package. If you don't >>>> export it, there will be no WARNING about it being undocumented. This >>>> variable is exported because of exportPattern(".") in the file >>>> NAMESPACE. The lone dot is a regular expression that matches any name >>>> of an R object. >>>> >>>> If you don't want to manually list your exports in the NAMESPACE file >>>> (which can get tedious) or generate it (which takes additional >>>> dependencies and build steps), you can use exportPattern('^[^\\.]') to >>>> export everything except objects with a name starting with a period: >>>> https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports >>>> >>>> -- >>>> Best regards, >>>> Ivan >>> >>> ______________________________________________ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> >> >> -- >> Joshua Ulrich | about.me/joshuaulrich >> FOSS Trading | http://www.fosstrading.com/ > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
