[R-pkg-devel] [patch] R CMD check when there are no .Rd examples
Hi,
Last week I submitted a new package to CRAN, and it was rejected
because there were no examples in any of the man pages. That's a
reasonable requirement--I just didn't know it was one. When I looked
back at the R CMD check results locally, I saw
* checking examples ... NONE
but the run still finished with
Status: OK
so I believed that my package was good. The package did have usage
examples in the test suite and on the readme file, and it was no
problem to copy the examples over to a man page and resubmit. But it
seemed like an unfortunate and avoidable waste of the CRAN
maintainers' time to have to ask for revisions and review again.
I read the source and saw that the requirement around .Rd examples
that R CMD check does enforce is only when there are no examples, no
vignettes, and no tests
(https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L5100-L5117).
The attached one-line patch makes the check for .Rd examples now log a
"Note" rather than just print "NONE". Running it against my package
without man-page examples, it shows
* checking examples ... NOTE
No examples
and ends with
Status: 1 NOTE
which should be enough to remind package authors to address it before
submitting to CRAN.
Thanks for considering this patch.
Neal
P.S. Since this is an issue about CRAN policy and package development,
I thought R-package-devel was the appropriate list to email, but
please let me know if I should send the patch to R-devel instead.
Index: src/library/tools/R/check.R
===
--- src/library/tools/R/check.R (revision 72665)
+++ src/library/tools/R/check.R (working copy)
@@ -2868,7 +2868,7 @@
" check also with --run-donttest\n")
}
} else {
-resultLog(Log, "NONE")
+noteLog(Log, "No examples")
no_examples <<- TRUE
}
}
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [patch] R CMD check when there are no .Rd examples
Thanks for the explanation. Is it possible for R CMD check to
distinguish between packages for which examples do or do not make
sense, and raise a "Note" as appropriate?
I really don't mean to make a big issue out of this particular (soft)
requirement--it was easy enough for you to spot and easy enough for me
to fix. But, this is the third or fourth time over the last few years
that I've submitted a package that passes R CMD check but have had to
revise and resubmit due to a similar minor requirement. I rely on
automation and tools, particularly R CMD check, to enforce
requirements so that I don't have to remember all of the subtleties of
"Writing R Extensions" and other policies. Yet, I now have a growing
list of additional checks that I have to remember to go through before
submitting, and it's easy to forget.
If 'R CMD check --as-cran' passes and CRAN rejects, it seems that the
tool is incomplete, and if it's feasible to improve it, we should. I'm
happy to try to prepare a different patch that better encapsulates
this particular policy.
Neal
On Wed, May 10, 2017 at 9:59 AM, Uwe Ligges
wrote:
> There are packages where examples do not make sense, hence we do not
> generally reject such packages.
>
> But if adding examples are reasonable we ask for them.
>
> Best,
> Uwe Ligges
>
>
>
>
> On 10.05.2017 17:28, Neal Richardson wrote:
>>
>> Hi,
>> Last week I submitted a new package to CRAN, and it was rejected
>> because there were no examples in any of the man pages. That's a
>> reasonable requirement--I just didn't know it was one. When I looked
>> back at the R CMD check results locally, I saw
>>
>> * checking examples ... NONE
>>
>> but the run still finished with
>>
>> Status: OK
>>
>> so I believed that my package was good. The package did have usage
>> examples in the test suite and on the readme file, and it was no
>> problem to copy the examples over to a man page and resubmit. But it
>> seemed like an unfortunate and avoidable waste of the CRAN
>> maintainers' time to have to ask for revisions and review again.
>>
>> I read the source and saw that the requirement around .Rd examples
>> that R CMD check does enforce is only when there are no examples, no
>> vignettes, and no tests
>>
>> (https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L5100-L5117).
>> The attached one-line patch makes the check for .Rd examples now log a
>> "Note" rather than just print "NONE". Running it against my package
>> without man-page examples, it shows
>>
>> * checking examples ... NOTE
>> No examples
>>
>> and ends with
>>
>> Status: 1 NOTE
>>
>> which should be enough to remind package authors to address it before
>> submitting to CRAN.
>>
>> Thanks for considering this patch.
>>
>> Neal
>>
>> P.S. Since this is an issue about CRAN policy and package development,
>> I thought R-package-devel was the appropriate list to email, but
>> please let me know if I should send the patch to R-devel instead.
>>
>>
>> patch.diff
>>
>>
>> Index: src/library/tools/R/check.R
>> ===
>> --- src/library/tools/R/check.R (revision 72665)
>> +++ src/library/tools/R/check.R (working copy)
>> @@ -2868,7 +2868,7 @@
>> " check also with --run-donttest\n")
>> }
>> } else {
>> -resultLog(Log, "NONE")
>> +noteLog(Log, "No examples")
>> no_examples <<- TRUE
>> }
>> }
>>
>>
>>
>> __
>> 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-pkg-devel] Clarifying CRAN's external libraries policy
Hi, CRAN's policy on using external C/C++/Fortran/other libraries says: "Where a package wishes to make use of a library not written solely for the package, the package installation should first look to see if it is already installed and if so is of a suitable version. In case not, it is desirable to include the library sources in the package and compile them as part of package installation. If the sources are too large, it is acceptable to download them as part of installation, but do ensure that the download is of a fixed version rather than the latest. Only as a last resort and with the agreement of the CRAN team should a package download pre-compiled software." Apologies if this is documented somewhere I've missed, but how does one get CRAN's agreement to download pre-compiled software? A project I work with has been seeking permission since October, but emails to both c...@r-project.org and cran-submissi...@r-project.org about this have not been acknowledged. I recognize that this mailing list is not CRAN, but I was hoping someone here might know the right way to reach the CRAN team to provide a judgment on such a request. Thank you, Neal [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement
CRAN policy [1] says: "If the sources are too large, it is acceptable to download them as part of installation, but do ensure that the download is of a fixed version rather than the latest." So you could try downloading the source in your configure script. Though be careful not to be bitten by this other line from the policy: "Packages which use Internet resources should fail gracefully with an informative message if the resource is not available or has changed (and not give a check warning nor error)." Neal [1]: https://cran.r-project.org/web/packages/policies.html On Wed, May 8, 2024 at 11:03 AM Josiah Parry wrote: > > I am sorry for blowing up this thread lately. > > I've submitted a package to CRAN that uses Rust which thus requires > dependencies to be vendored. https://github.com/R-ArcGIS/arcgisutils/ > > The vendored dependencies are 18mb when zipped and 16.4mb when zipped with > XZ -9e. The *installed package size is 1.2mb* on my Mac. > > CRAN has rejected this package with: > > * Size of tarball: 18099770 bytes* > > *Please reudce to less than 5 MB for a CRAN package.* > > > Due to the requirement to vendor my dependencies. I do not see any possible > way to compress 250mb of source code to <= 5mb. > > I suspect there are alternatives which have been handled in one-off > situations given that other packages require fairly large system > dependencies e.g. Arrow, DuckDB, torch etc. > > How do others handle this? > > [[alternative HTML version deleted]] > > __ > 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] Needing rgeos from sf
A couple of ideas:
1. Both `sf` and `sp` packages Suggest rgdal and rgeos. If your
package were to Suggest them, the dependencies will be available for
CRAN checks, but they won't be available if they're only Suggested by
a package you Import.
2. Except sometimes when they are available. I've experienced
variability in this before, depending on which CRAN server you run on
and which other packages have recently been checked on it (I think
that's the reason). In your case, it could have something to do with
rgdal/rgeos availability on Windows, but the operating system might be
a red herring. Regardless, it looks like you've found a solution.
Neal
On Thu, Jul 25, 2019 at 1:49 PM Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
>
> Thanks, actually have similar code for some other packages that must have
> been causing similar problems (that part was from the original author, I am
> now the maintainer). Now I understand why he had something similar in the
> code. There is a comment about Namespaces not being handled properly in
> those packages.
>
> Will try that. I actually have rgdal and rgeos in Imports, they were
> getting flagged in the CRAN nightly builds. If I have them in that one
> statement, that should take care of both issues I believe.
>
> But it would be nice to figure out why this is happening, and only on
> Windows. Sort of frustrating when you follow the guidelines but get
> failures, but what also what is good about things like CRAN, for whatever
> reason this will insure I work across platforms.
>
> -Roy
>
>
> > On Jul 25, 2019, at 12:56 PM, Duncan Murdoch
> > wrote:
> >
> > On 25/07/2019 3:47 p.m., Roy Mendelssohn - NOAA Federal wrote:
> >> Okay I added rgeos but now it can't find rgdal. as in:
> >>> Error: processing vignette 'using_plotdap.Rmd' failed with diagnostics:
> >>> package 'rgdal' is not available
> >>> --- failed re-building 'using_plotdap.Rmd'
> >>>
> >> A question I asked before is if there is anyway to check that 'rgdal' and
> >> 'rgeos' are properly installed on the winbuider servers, as well as 'sf'
> >> and 'sp'? 'devtools::check()' on my mac produces no errors, same with
> >> 'rhub' using Fedora, but I get the same errors on 'rhub' using Windows.
> >> So it appears to be a problem with Windows, and again I am not calling
> >> these packages directly so I should not need to Import them.
> >
> > You're right, you shouldn't need to import them if you don't call them
> > directly. However, if some package that you do need requires them, then
> > your build or checks will fail without them.
> >
> > It's probably getting tedious, but you could work around this as well, by
> > figuring out what part of using_plotdap.Rmd needs rgdal, and wrapping that
> > code in something like
> >
> > if (requireNamespace("rgdal")) {
> > # code that needs it
> > }
> >
> > I think this will mean you need to add rgdal to the Suggests list for your
> > package to avoid other warnings.
> >
> > Duncan Murdoch
> >
> >> Thanks,
> >> -Roy
> >>> On Jul 25, 2019, at 12:38 PM, Duncan Murdoch
> >>> wrote:
> >>>
> >>> On 25/07/2019 3:21 p.m., Roy Mendelssohn - NOAA Federal via
> >>> R-package-devel wrote:
> I have been testing a package for resubmission with bug fixes. On the
> present CRAN builds I get:
> > Result: NOTE
> > Namespaces in Imports field not imported from:
> > ‘mapdata’ ‘maptools’ ‘plot3D’ ‘rgdal’ ‘rgeos’
> > All declared Imports should be used.
> However, if I remove rgeos from the imports I get from win builder:
> > Error in st_as_sfc.SpatialPolygons(sp::geometry(x), ...) :
> > package rgeos required for finding out which hole belongs to which
> > exterior ring
> Note that I am not calling 'rgeos', either 'sf' or 'sp' is, but does
> not appear to be properly importing all the need namespaces.
> Best way to proceed? Include rgeos in Import and get the Note, or
> >>>
> >>> A simple workaround would be to add a function that calls something from
> >>> rgeos just to satisfy the check, e.g.
> >>>
> >>> # Just to satisfy the checks...
> >>> dummy <- function() rgeos::getScale()
> >>>
> >>> I don't think there are warnings if dummy is never used or exported, but
> >>> if there are, I think that's a pretty harmless call to make.
> >>>
> >>> Duncan Murdoch
> >> **
> >> "The contents of this message do not reflect any position of the U.S.
> >> Government or NOAA."
> >> **
> >> Roy Mendelssohn
> >> Supervisory Operations Research Analyst
> >> NOAA/NMFS
> >> Environmental Research Division
> >> Southwest Fisheries Science Center
> >> ***Note new street address***
> >> 110 McAllister Way
> >> Santa Cruz, CA 95060
> >> Phone: (831)-420-3666
> >> Fax: (831) 420-3980
> >> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
> >> "Old age and treachery will overcome youth and skill."
> >> "From those w
Re: [R-pkg-devel] Testing on old R versions
I've used the https://hub.docker.com/r/rstudio/r-base images for this, and they appear to go back to R 3.1. Likewise https://hub.docker.com/r/rocker/r-ver. The latter uses MRAN to install packages from a CRAN snapshot corresponding to the release, so that should also help with dependencies. Neal On Thu, Jan 28, 2021 at 7:06 AM Duncan Murdoch wrote: > I just received a bug report about the rgl package: it claims to depend > on R >= 3.2.0, but actually uses the hcl.colors() function that was > introduced in R 3.6.0, so fails to install. (This dependence was > introduced while I had the dependence stated as R >= 4.0.0 for a while, > until I tried to help people stuck on old releases; I fixed some of the > 4.0.0 needs, but missed this one.) > > So of course what I should have done was to run the checks on R 3.2.0 > (and maybe intermediate versions) to confirm it works, but I didn't try > that before releasing to CRAN. > > I've just finished installing a copy of R 3.2.0 and testing my fix, so I > think things are fine now. This took some work; some of the packages > used by the current rgl didn't exist when R 3.2.0 was current, so no > binaries exist for them; installing the tools for binary builds takes > time, etc. > > So finally, my question: what is the recommended way to handle tests of > new packages on old R versions? Do docker or other images exist that > are already set up and ready to go? > > Duncan Murdoch > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
