Skip to content

[Bioc-devel] _R_CHECK_FORCE_SUGGESTS_ = false

8 messages · Paul Shannon, Henrik Bengtsson, Yue Li +2 more

#
Dear list,

I just submitted a new package. It builds and checks OK on the Mac and Linux servers but fails to build on the Windows server, namely 'mosacto1'. The error says:

* checking package dependencies ... ERROR
Package suggested but not available: 'multicore'

The suggested packages are required for a complete check.
Checking can be attempted without them by setting the environment
variable _R_CHECK_FORCE_SUGGESTS_ to a false value.

But it seems that I can only set that environment variable _R_CHECK_FORCE_SUGGESTS_ in ~/.R/check.Renviron on my local machine not on the server. I wonder if anyone encountered the same problem when trying to submit your package before? I apologize if the issue has been addressed in some other posts that I failed to find it by Google.

Thanks in advance,
Yue
#
Dear Yue Li,

I am not the expert on this that Dan and Martin are, but I am pretty sure the solution is to use the parallel package rather than multicore.  Using parallel, your package should build on all architectures.

This is from the man page:

Direct support in R is starting with release 2.14.0 which includes a new package parallel incorporating (slightly revised) copies of packages multicore and snow (but excluding MPI, PVM and NWS clusters). Code written to use the higher-level API functions in those packages should work unchanged (apart from changing any references to their namespaces to a reference to parallel, and links explicitly to multicore or snow on help pages). 

 - Paul
On Sep 15, 2012, at 7:40 AM, Yue Li wrote:

            
#
Here's another example of this:

http://bioconductor.org/checkResults/devel/bioc-LATEST/PANR/moscato1-checksrc.html

Question to BioC core: Why not sticking with the default
_R_CHECK_FORCE_SUGGESTS_=FALSE?  I see a suggested package as a
package that is not required except in rare cases.  I also sometimes
use them to complement each other, e.g. part of my code prefer package
A but if that doesn't exist it's fall back to use package B.  It's up
to the developer to write examples()/system tests that don't generate
R CMD check errors in these cases, and if they forget, then ...yes...
R CMD check will generate an ERROR anyway.

/Henrik
On Sat, Sep 15, 2012 at 7:40 AM, Yue Li <gorillayue at gmail.com> wrote:
#
On Sat, Sep 15, 2012 at 8:29 AM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:
My bad: It's TRUE by default

<quote>
_R_CHECK_FORCE_SUGGESTS_
If true, give an error if suggested packages are not available.
Default: true (but false for CRAN submission checks).
</quote>

(I've been using --as-cran to much lately).  Still standing by my
comments below though.
/Henrik

PS. Yue, I don't it's not possible for the package to control these
flags/settings.
#
Thanks Paul. That fixed the problem!

Yue
On 2012-09-15, at 10:53 AM, Paul Shannon <pshannon at fhcrc.org> wrote:

            
#
I agree with you Henrik. More flexibility is needed for package builders.

Yue
On 2012-09-15, at 12:00 PM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:

            
#
On 09/15/2012 09:00 AM, Henrik Bengtsson wrote:
The more usual scenario is that suggested packages are used during build 
or check but not by the installed package, e.g., suggested packages used 
in vignettes or perhaps unit tests. It's hard enough to write and 
support code that works consistently across platforms, so you're a brave 
person to want to write code that also supports different package 
configurations.

_R_CHECK_FORCE_SUGGESTS_=TRUE restricts the universe of available 
packages to those on cran and Bioc (mostly), which have at least a 
modicum of testing and general availability that would seem to be desirable.

Not meant to be the final word on the _R_CHECK_FORCE_SUGGESTS_ flag.

Martin