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 
     > 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")

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

    For packages with many variables to export it may be more convenient
to specify the names to export with a regular expression using
‘exportPattern’.  The directive


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.


     >> 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> 
     >>> 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 
     >> 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 
     >>>>> 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:
     >>>> --
     >>>> 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

R-package-devel@r-project.org mailing list

Reply via email to