Skip to content

[R-pkg-devel] nit-picking about CRAN repository policy

9 messages · Dirk Eddelbuettel, Ben Bolker, Duncan Murdoch +3 more

Original
Ben Bolker
# 
Folks,

   CRAN has recently set up an auxiliary 'noSuggests' test platform that 
tests that packages are using suggested packages conditionally, as 
recommended in Writing R Extensions, and as (sort of) specified in the 
CRAN repository policy.

   Specifically, the CRP (revision 5236) says:

 > A package listed in ?Suggests? or ?Enhances? should be used 
conditionally in examples or tests if it cannot straightforwardly be 
installed on the major R platforms. (?Writing R Extensions? recommends 
that they are always used conditionally.)

   One of my packages failed on the 'noSuggest' test platform 
<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/bbmle.out> because two 
suggested packages were used unconditionally in the vignette. There are 
two reasons (IMO) that this should *not* have triggered a threat of 
archiving:

   (1) the unconditional package use was in a vignette, not in examples 
or tests
   (2) the relevant packages (AICcmodavg and MuMIn) are available on 
CRAN and install easily on Linux/Windows/MacOS (they are R-only, no 
compiled code or extra requirements, binaries are available on CRAN).

    Is it worth suggesting to CRAN maintainers that either they refine 
their 'noSuggests' test so that it conforms to the wording in the CRP, 
or that they change the CRP wording to something stricter like

 > Any package listed in ?Suggests? or ?Enhances? should be used 
conditionally in examples, tests, and vignettes.

  ?

   cheers
     Ben Bolker
Dirk Eddelbuettel
# 
While I of course do not speak for CRAN, allow me (given I've harped on this
beat before [1]) to record a strong disagreement here: "unconditionally used"
is simply not reflecting the conditional nature of a Suggests, nomatter where
it happens in the package.  Vignettes are no different from examples.

So I say thanks to CRAN for having gradually sharpened the language in the
CRAN Repo Policu over the years and for now adding even more explicit tests.

Dirk

[1] One such post is "Suggests != Depends which is at
https://dirk.eddelbuettel.com/blog/2017/03/22/#suggests_is_not_depends
Duncan Murdoch
#
On 07/05/2022 6:43 p.m., Ben Bolker wrote:
I wouldn't think it's worth the time, but you could submit a suggested 
patch to them if you feel like it.

Personally I'd take a more extreme position than theirs:  your package 
should check without errors if any subset of the Suggests packages is 
installed.  This isn't practical to test, but "all" and "none" is at 
least something.

With vignette formats based on knitr, it's very easy to implement this. 
  Just add a code chunk at the beginning with code like this:

   if (!requireNamespace("sug1") ||
       !requireNamespace("sug2")) {
     warning(call. = FALSE, "This vignette requires sug1 and sug2 to be 
installed")
     knitr::knit_exit()
   }

I don't know if other vignette engines make it so easy to bail out, but 
they should.

Duncan Murdoch
Ben Bolker
#
On 2022-05-07 7:17 p.m., Duncan Murdoch wrote:
Thanks.

   Fixing the problems isn't difficult or unreasonable (I will do it in 
a more subtle way, running chunks of code conditionally). I'm just 
feeling a little bit grumpy/defensive because:

  * CRAN  asked me to submit a patched version before May 7
  * I submitted a patched version to CRAN at 7:30 PM local time on May 6 
(which is admittedly May 7 in UK/European time)
* I woke up to an e-mail from CRAN to me and 50 downstream package 
maintainers saying that my package was scheduled for archiving, and a 
concerned message from a downstream package maintainer ...

   cheers
    Ben B.
Duncan Murdoch
#
On 07/05/2022 7:30 p.m., Ben Bolker wrote:
As far as I know, the folks at CRAN are *always* grumpy.

Duncan
Simon Urbanek
# 
Ben,

I fully agree with Dirk - it would be good to make the CRP more clear.

The main problem with failing to the check conditional dependencies is in cases where there are circular dependencies: package A suggests B, and package B requires A. The correct resolution is to check A without B, then check B with A and then check A with B (that's what the macOS CRAN build system is doing). If A fails to check without B, the whole chain is doomed and none of the package will be available.

So at the very least the examples and tests should be clearly conditional. Currently, the vignettes also required since there is no specific check with --no-build-vignettes.

As for your package, the fact that it worked so far is due to the incremental nature of the builds: if your dependency is not circular then the build system will schedule dependencies for check before your package which is possible in that case, so the package is actually never checked without the suggests. In the macOS case we have no choice, because there are so many packages to build that checking every suggests-dependency twice would take too long. So from practical point of view, the suggests-must-be-conditional rule has been checked only for packages with circular dependencies since that is where it matters the most. However, the circular nature is not a function of the package itself, so it could make sense to make it global, since you don't know if the package you suggest may ever depend on your package and suddenly break your package that way. This is just my pragmatic view, I don't know any specific details on the noSuggests checks per se.

Cheers,
Simon
Ben Bolker
#
On 2022-05-07 6:54 p.m., Dirk Eddelbuettel wrote:
Dirk and Simon: to be clear, I'm not objecting to the new tests, just 
to the fact that they don't match the published repository policy.

(and conditioned on a mildly annoying CRAN interaction as described 
elsewhere in the thread 
<https://stat.ethz.ch/pipermail/r-package-devel/2022q2/008040.html>).

   cheers
    Ben
1 day later
Sebastian Meyer
# 
In my opinion, vignettes -- as opposed to examples and tests -- should 
be allowed to depend on suggested packages without having to 
conditionalize their use in the code (if they can straightforwardly be 
installed on the major R platforms). The vignette system is already 
prepared to handle \VignetteDepends metadata, which is checked to only 
list packages from the DESCRIPTION Depends/*Suggests*/Imports entries. R 
CMD check could skip vignette processing if the stated requirements are 
not fulfilled -- possibly with a note citing WRE that suggested packages 
are needed for a complete check, similar to the note that we'd already 
get from the "checking package dependencies" step: "Package suggested 
but not available for checking".

I think such a setup would highlight the importance of vignette 
reproducibility (whereas conditionalizing suggested packages would 
simply give OK without having executed all the code), but reduces the 
amount of failures on check servers when vignette dependencies become 
unavailable.

There is a related report in R's Bugzilla 
<https://bugs.r-project.org/show_bug.cgi?id=18318>.

Best regards,

	Sebastian Meyer


Am 09.05.22 um 00:13 schrieb Simon Urbanek:
1 day later
Neal Fultz
# 
Is there a status code I could use to signal early-stopping due to
missing dependencies (eg in test scripts)?

I am thinking of writing something like:

    require(suggested_pkg) || quit(status=13)

I checked ?quit which says:

     Some error status values are used by R itself.  The default error
     handler for non-interactive use effectively calls 'q("no", 1,
     FALSE)' and returns error status 1.  Error status 2 is used for R
     'suicide', that is a catastrophic failure, and other small numbers
     are used by specific ports for initialization failures.  It is
     recommended that users choose statuses of 10 or more.

Probably there's already an error code for a missing dependency. I
would imagine the list of status codes exists somewhere, but I wasn't
able to find it easily with "man R" / google / SO / rseek.
On Mon, May 9, 2022 at 3:58 PM Sebastian Meyer <seb.meyer at fau.de> wrote: