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

>      exportPattern("^[^\\.]")

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

Reply via email to