>>>>> Joshua Ulrich >>>>> on Wed, 6 Mar 2024 10:57:28 -0600 writes:
> 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 agree: at least use exportPattern("^[^\\.]") instead of the 'very un-recommended' (.) which -- as Ivan mentioned -- does export *everything* -- entirely destroying one important advantage of namespaces, namely to have "private" auxiliary functions/objects/data . Martin >> 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 | > 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