Re: [R-pkg-devel] advice on a rejected package (I think, because time was 13min, in excess of 10min limit)

2022-05-11 Thread Dirk Eddelbuettel


On 11 May 2022 at 19:07, Daniel Kelley wrote:
| Today I tried to update the CRAN oce package to version 1.7-3, to address a 
problem with 1.7-2 on one of the CRAN build platforms.  I used 
devtools::release() to submit it.  I just received the text I've pasted at the 
bottom of this email.  I've checked all the links, and my impression is that 
the sole problem is that the build took 13 minutes, which is over a 10-minute 
limit.
| 
| Since oce is a big package, I am not sure that removing the tests and 
documentation examples would reduce the time by 30%. There is a lot of C, C++ 
and fortran code that takes a while to build. And a package lacking code 
examples and a test suite is not likely to please my users, many of whom are 
scientists without deep coding experience.
| 
| During the previous submission, this time limit flag was also raised, and I 
asked R-package-devel for advice on what to do.  Someone suggested that I wait 
a week, in case a CRAN member would notice and put the package through. That 
worked, but my concern is whether this is the approach that makes for less work 
on the CRAN side.
| 
| So, I wonder whether the advice on this list is again to leave it alone and 
wait, or to contact CRAN?

The 'Overall checktime 13 min > 10 min' suggests to me that you should
condition some tests on an environment variable possibly present on your home
system, your CI setup, ... but not CRAN so that the default gets closer to
five minutes.

Of course it sucks that we have to reduce coverage but CRAN is also testing
18.5k packages, often recursively or in bulk when changes are considered to
time matters. So it is a defensible tradeoff.

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] nit-picking about CRAN repository policy

2022-05-11 Thread 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  wrote:
>
> 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
> .
>
> Best regards,
>
> Sebastian Meyer
>
>
> Am 09.05.22 um 00:13 schrieb 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
> >
> >
> >
> >> On 8/05/2022, at 10:43 AM, Ben Bolker  wrote:
> >>
> >>
> >>   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 
> >>  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 exam