Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz
On 06/03/2024 1:00 p.m., Martin Maechler wrote:
Richard M Heiberger
on Wed, 6 Mar 2024 17:10:50 + 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-exports
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 .,
they should have to consciously choose so.
Martin
>> On Mar 6, 2024, at 11:57, Joshua Ulrich wrote:
>>
>> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger
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 wrote:
В Tue, 5 Mar 2024 22:41:32 +
"Richard M.
Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz
> Richard M Heiberger
> on Wed, 6 Mar 2024 17:10:50 + 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.
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-exports
>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 .,
they should have to consciously choose so.
Martin
>> On Mar 6, 2024, at 11:57, Joshua Ulrich wrote:
>>
>> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger
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 wrote:
В Tue, 5 Mar 2024 22:41:32 +
"Richard M. Heiberger" пишет:
> 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
Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz
> Joshua Ulrich
> on Wed, 6 Mar 2024 10:57:28 -0600 writes:
> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger
> 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
>> wrote:
>> >
>> > В Tue, 5 Mar 2024 22:41:32 + > "Richard
>> M. Heiberger" пишет:
>> >
>> >> 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
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
Dear all,
Thank you for your proposals and discussions. Accordingly, because it seems
there is no relevant alternative, I decided to propose an update of the «
survivalmodels » instead of the initial maintener for repositioning it in the
main CRAN repository and avoid the archiving of my package.
Thanks again.
Yohann
> Le 5 mars 2024 à 22:25, Dirk Eddelbuettel a écrit :
>
>
> On 5 March 2024 at 15:12, Duncan Murdoch wrote:
> | On 05/03/2024 2:26 p.m., Dirk Eddelbuettel wrote:
> | > The default behaviour is to build after every commit to the main branch.
> But
> | > there are options. On the repo I mentioned we use
> | >
> | > "branch": "*release",
> |
> | Where do you put that? I don't see r2u on R-universe, so I guess you're
> | talking about a different repo; which one?
>
> In the (optional) control repo that can drive your 'r-universe', and the file
> has to be named 'packages.json'. For you the repo would
>
>https://github.com/dmurdoch/dmurdoch.r-universe.dev
>
> (and the naming rule was tightened by Jeroen recently -- we used to call
> these just 'universe', now it has to match your runiverse)
>
> The file packages.json would then have a block
>
> {
>"package": "rgl",
>"maintainer": "Duncan Murdoch "
>"url": "https://github.com/dmurdoch/rgl;,
>"available": true,
>"branch": "*release"
> }
>
> The reference I mentioned is our package 'tiledbsoma' (joint work of TileDB
> and CZI, in https://github.com/single-cell-data/TileDB-SOMA) and described
> here:
>
> https://github.com/TileDB-Inc/tiledb-inc.r-universe.dev/blob/master/packages.json
>
>
> (and you can ignore the '"subdir": "apis/r"' which is a facet local to that
> repo).
>
> Note that 'my' packages.json in my eddelbuettel.r-universe.dev ie
>
> https://github.com/eddelbuettel/eddelbuettel.r-universe.dev/blob/master/packages.json
>
> also describe but without the '"branch": "*release"' and that builds with
> every merge to
> the main branch by my choice; that build is mine and 'inofficial' giving us
> two.
>
> | > It is under your control. You could document how to install via `remotes`
> | > from that branch. As so often, it's about trading one thing off for
> another.
> |
> | I do that, but my documentation falls off the bottom of the screen, and
> | the automatic docs generated by R-universe are at the top.
>
> I always get lost in the r-universe docs too. Some, as Jeroen kindly reminded
> me the other day, are here: https://github.com/r-universe-org
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz
Thank you, I will do that reversion in a few days.
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("^[^\\.]") ?
> On Mar 6, 2024, at 11:57, Joshua Ulrich wrote:
>
> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger 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 wrote:
>>>
>>> В Tue, 5 Mar 2024 22:41:32 +
>>> "Richard M. Heiberger" пишет:
>>>
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
Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz
On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger 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 wrote:
> >
> > В Tue, 5 Mar 2024 22:41:32 +
> > "Richard M. Heiberger" пишет:
> >
> >> 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
