Skip to content

[R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally

15 messages · Michael Friendly, Dirk Eddelbuettel, Jeff Newmiller +3 more

Original
Michael Friendly
# 
I got the email below concerning 3 of my packages but wonder if they are false alarms or
if not, how to locate & fix the problem.

    This concerns packages: ...

    Suggested packages should be used conditionally: see ?1.1.3.1 of 'Writing R Extensions'.  Some of these are hard to install on a platform without X11 such as M1 Macs: see the logs at https://www.stats.ox.ac.uk/pub/bdr/M1mac/.

    You can check all of the suggested packages by setting environment variable _R_CHECK_DEPENDS_ONLY_=true  -- see https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .

Is this a false alarm?

In each case, the outfile contains:

    * checking package namespace information ... OK
    * checking package dependencies ... NOTE
    Package suggested but not available for checking: 'rgl'

indicating that rgl is not avaiable on the testing machine.  Then, when checking examples an error is triggered
when an example calls something that requires rgl.

    >
    > heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
    +         col = c("red", "blue", "black", "gray"), wire=FALSE)
    Loading required namespace: rgl
    Failed with error:  'there is no package called 'rgl''
    Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg = c("AMED", "BMIQ")),  :
      rgl package is required.
    Calls: heplot3d -> heplot3d.mlm
    Execution halted

Yet, heplot3d seems to contain the required way to refer to the suggested rgl package:

                if (!requireNamespace("rgl")) stop("rgl package is required.")

So, I'm mystified.  Can anyone help?



Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Former Chair, ASA Statistical Graphics Section
York University      Voice: 416 736-2100 x66249
4700 Keele Street    Web: http://www.datavis.ca | @datavisFriendly
Toronto, ONT  M3J 1P3 CANADA
Dirk Eddelbuettel
#
On 12 December 2020 at 16:24, Michael L Friendly wrote:
| I got the email below concerning 3 of my packages but wonder if they are false alarms or
| if not, how to locate & fix the problem.
| 
|     This concerns packages: ...
| 
|     Suggested packages should be used conditionally: see ?1.1.3.1 of 'Writing R Extensions'.  Some of these are hard to install on a platform without X11 such as M1 Macs: see the logs at https://www.stats.ox.ac.uk/pub/bdr/M1mac/.
| 
|     You can check all of the suggested packages by setting environment variable _R_CHECK_DEPENDS_ONLY_=true  -- see https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .
| 
| Is this a false alarm?
| 
| In each case, the outfile contains:
| 
|     * checking package namespace information ... OK
|     * checking package dependencies ... NOTE
|     Package suggested but not available for checking: 'rgl'
| 
| indicating that rgl is not avaiable on the testing machine.  Then, when checking examples an error is triggered
| when an example calls something that requires rgl.
| 
|     >
|     > heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
|     +         col = c("red", "blue", "black", "gray"), wire=FALSE)
|     Loading required namespace: rgl
|     Failed with error:  'there is no package called 'rgl''
|     Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg = c("AMED", "BMIQ")),  :
|       rgl package is required.
|     Calls: heplot3d -> heplot3d.mlm
|     Execution halted
| 
| Yet, heplot3d seems to contain the required way to refer to the suggested rgl package:
| 
|                 if (!requireNamespace("rgl")) stop("rgl package is required.")
| 
| So, I'm mystified.  Can anyone help?

This is not conditional use in the sense of my reading of WRE.

What you have here is essentially an "assert()" and equivalent to
  stopifnot(requireNamespace("rgl"))
which, in turn, is equivalent to a strong Depends or Imports as your package
will experience a _critical error_ triggered by `stop()` if rgl is missing.

The idea of a conditional use is to, well, be conditional. Below I make use
of Rcpp if is present, but it is only a suggests:

  ## see the source files in the snippets/ directory of the package
  ## check for (optional, only in Suggests:) Rcpp, and also wrapped in a
  ## dontrun as it takes 10s at CRAN (yet only 3.5 here) yielding a NOTE
  if (requireNamespace("Rcpp", quietly=TRUE)) {
      Rcpp::sourceCpp(system.file("snippets", "convolveExample.cpp", package="tidyCpp"))
  }

If the _suggested_ package is present, it is used. If not we quietly move on. 
(It's not the full story as the compilation occassionally takes longer,
Windows complained so all this is now in a \dontrun{} block too. But the idea
is generic and there are many more examples to be found.)

Hope this helps,  Dirk
Jeff Newmiller
# 
Examples should use dontrun to avoid calling functions that call stop.
On December 12, 2020 8:24:50 AM PST, Michael L Friendly <friendly at yorku.ca> wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
I think you're supposed to skip the example (throwing a warning, if 
you like ...) if rgl isn't available, rather than throwing an error ... ?

        
On 12/12/20 11:24 AM, Michael L Friendly wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Michael Friendly
    

    

      
      #
    

  


  

      
Thanks, Dirk

Just to clarify--
In my packages, candisc, heplots, vcdExtra I have mostly 2D graphic methods, but some 3D methods that use
rgl.  I therefore put rgl into Suggests:

Could I solve this by making rgl a Depends: ?

-Michael


-----Original Message-----
From: Dirk Eddelbuettel <edd at debian.org> 
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly <friendly at yorku.ca>
Cc: r-package-devel at R-project.org; Prof Brian Ripley <ripley at stats.ox.ac.uk>
Subject: Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally

        
On 12 December 2020 at 16:24, Michael L Friendly wrote:

        
| I got the email below concerning 3 of my packages but wonder if they 
| are false alarms or if not, how to locate & fix the problem.
| 
|     This concerns packages: ...
| 
|     Suggested packages should be used conditionally: see  1.1.3.1 of 'Writing R Extensions'.  Some of these are hard to install on a platform without X11 such as M1 Macs: see the logs at https://www.stats.ox.ac.uk/pub/bdr/M1mac/.
| 
|     You can check all of the suggested packages by setting environment variable _R_CHECK_DEPENDS_ONLY_=true  -- see https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .
| 
| Is this a false alarm?
| 
| In each case, the outfile contains:
| 
|     * checking package namespace information ... OK
|     * checking package dependencies ... NOTE
|     Package suggested but not available for checking: 'rgl'
| 
| indicating that rgl is not avaiable on the testing machine.  Then, 
| when checking examples an error is triggered when an example calls something that requires rgl.
| 
|     >
|     > heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
|     +         col = c("red", "blue", "black", "gray"), wire=FALSE)
|     Loading required namespace: rgl
|     Failed with error:  'there is no package called 'rgl''
|     Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg = c("AMED", "BMIQ")),  :
|       rgl package is required.
|     Calls: heplot3d -> heplot3d.mlm
|     Execution halted
| 
| Yet, heplot3d seems to contain the required way to refer to the suggested rgl package:
| 
|                 if (!requireNamespace("rgl")) stop("rgl package is 
| required.")
| 
| So, I'm mystified.  Can anyone help?

This is not conditional use in the sense of my reading of WRE.

What you have here is essentially an "assert()" and equivalent to
  stopifnot(requireNamespace("rgl"))
which, in turn, is equivalent to a strong Depends or Imports as your package will experience a _critical error_ triggered by `stop()` if rgl is missing.

The idea of a conditional use is to, well, be conditional. Below I make use of Rcpp if is present, but it is only a suggests:

  ## see the source files in the snippets/ directory of the package
  ## check for (optional, only in Suggests:) Rcpp, and also wrapped in a
  ## dontrun as it takes 10s at CRAN (yet only 3.5 here) yielding a NOTE
  if (requireNamespace("Rcpp", quietly=TRUE)) {
      Rcpp::sourceCpp(system.file("snippets", "convolveExample.cpp", package="tidyCpp"))
  }

If the _suggested_ package is present, it is used. If not we quietly move on. 
(It's not the full story as the compilation occassionally takes longer, Windows complained so all this is now in a \dontrun{} block too. But the idea is generic and there are many more examples to be found.)

Hope this helps,  Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
I have tests in my code to detect when something like that is not 
available.


	  I also have code in "\examples" to skip tests that would encounter 
that.


	  Hadley's "testthhat:skip_on_cran" is supposed to suppress tests like 
that on CRAN.  I have so far failed to understand how to use this 
function that Hadley wrote.  Instead, I use things like the following:


if(!fda::CRAN()){
# Code that I want to run everyplace that's NOT CRAN


}


	  When I wrote "fda::CRAN", I was told that I shouldn't do it, but I 
didn't see a better option, and I've been using it for several years now 
without being given a reason to discontinue using it or (better?) being 
given an alternative that seems better to me.


	  Spencer

        
On 2020-12-12 12:40, Michael L Friendly wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
Apologies if I'm telling you something you already know:

   By default, fda::CRAN() uses the presence of environment variables 
matched by the regexp "^_R_" as a heuristic to decide whether it's being 
running on CRAN.

   testthat::skip_on_cran()  calls testthat::on_cran() to look for an 
environment variable called NOT_CRAN equal to "true". The 
devtools::check() machinery automatically sets this variable.


   So: fda::CRAN() depends on breakable assumptions, defaults to FALSE 
in an empty environment.  skip_on_cran() defaults to TRUE in an empty 
environment (but defaults to FALSE in a devtools::check() environment).

        
On 12/12/20 2:19 PM, Spencer Graves wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
Hi, Ben et al.:

        
On 2020-12-12 13:43, Ben Bolker wrote:

            

      
      
      
    

        
> testthat::on_cran
Error: 'on_cran' is not an exported object from 'namespace:testthat'


	  Besides, on my Mac, I get:


 > testthat:::on_cran()
[1] TRUE


	  My Mac is NOT CRAN, and I don't want that function to return TRUE on 
my computer unless I explicitly run "R CMD check --on-cran".

            

      
      
      
    

        
If future changes break fda::CRAN, I will have to deal with it then.


	  I'd be happier if the CRAN maintainers would develop a procedure to 
make it easier for package maintainers do two things:


		    * Include tests in their package that run longer than the time 
limit permitted on CRAN.


		    * Give error messages that the package maintainer wants to see but 
that should be suppressed on CRAN or when the user decides to run "R CMD 
check --as-cran".


	  In any event, I hope that I'll be able to continue using fda::CRAN as 
I have been.  If not, I will be forced to reduce the coverage of test 
suites everywhere I use fda::CRAN.  That in turn will make the code 
harder to maintain and more easily broken in ways that I can no longer 
easily test.


	  Spencer

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
On 12/12/20 4:08 PM, Spencer Graves wrote:

            

      
      
      
    

        
on_cran() is intended to be used via testthat::skip_on_cran() 
(which is exported, unlike on_cran()).

            

      
      
      
    

        
The assumption of testthat is that it's going to be deployed via 
devtools::check(), which automatically sets the environment variable 
NOT_CRAN equal to 'true'. For testing on your machine, you could use

Sys.setenv(NOT_CRAN="true"); testthat:::on_cran()

or you could put

export NOT_CRAN=true

in the shell/in your testing pipeline.

            

      
      
      
    

        
I agree that this would be nice.

   A simple mechanism would be to set an official/sanctioned/stable 
environment variable such as _R_ON_CRAN in all CRAN testing pipelines.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 12/12/2020 4:08 p.m., Spencer Graves wrote:

            

      
      
      
    

        
That's very easy now.  Just put them in a "slowtests" directory, and 
tell R CMD check to use that.  How could it be easier?

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 12/12/2020 4:41 p.m., Ben Bolker wrote:

            

      
      
      
    

        
What's wrong with users setting NOT_CRAN on all non-CRAN testing pipelines?

Most people want the same tests in both places.  Those who like writing 
lots of time consuming tests are the ones who shouldn't mind a small 
step to control them.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
On 12/12/20 5:50 PM, Duncan Murdoch wrote:

            

      
      
      
    

        
How would you do that?  In "R CMD check --help" I see that one can 
use --test-dir= to specify the test directory, but I don't see a way to 
specify _additional_ test directories; short of setting a tests/ 
directory with CRAN-specific tests and a slowtests/ directory with 
*both* CRAN-specific and CRAN-excluded tests (thus duplicating files, 
which seems clunky), I don't see how to do this within a standard R CMD 
check framework (without testing a CRAN-indicating environment variable, 
which gets us back where we started ...)  Or would you run R CMD check 
twice, once without and once with --test-dir=slowtests ?

   There doesn't seem to be very much in "Writing R Extensions" about 
testing - a little bit in
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories

   What am I missing?

  Just to clarify, the ideal would be to be able to designate a separate 
set of tests that were *not* run on CRAN, and to be able to run them in 
the same "R CMD check" pass as the CRAN-specific tests.  There are a 
bunch of ways to achieve this, but I think Spencer is saying (and I 
agree) that it would be nice if it were there an official mechanism that 
made this easier (and it seems pretty easy if the CRAN maintainers were 
agreeable to the idea ...)

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
On 12/12/20 5:53 PM, Duncan Murdoch wrote:

            

      
      
      
    

        
This is where we started. Nothing's wrong with it, but setting 
_R_CRAN=true on CRAN testing pipelines and providing an on_cran() 
function in the utils package would also seem almost trivially easy for 
R-core/CRAN maintainers, and would simplify the process for R package 
developers who are less familiar with shell/scripting/etc. (although I 
admit that (wanting_to_skip_tests && not_familiar_with_env_vars && 
not_working_in_devtoolsverse) could be a small intersection ...)

            

      
      
      
    

        
True. It doesn't take that much to exceed 10 minutes on the CRAN 
windows pipeline any more, though.  I have 56 separate test files in 
lme4; on the Windows pipeline it takes 3 seconds just to *load* the lme4 
package, and every file gets tested on ix386 and x86_64, so I would use 
up about 6 minutes of my 10-minute checking budget before I even got 
started ...

    (Yes, I know I could combine the files so that I have to load the 
package less often during the testing phase, or possibly eliminate the 
library() calls - I don't remember whether test files have to run in a 
standalone R session, although it certainly seems like best practice).

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 12/12/2020 6:01 p.m., Ben Bolker wrote:

            

      
      
      
    

        
What I would do is have the slowtests run the regular tests.  So if I 
want both, I run slowtests.  If I want just the fast ones, I don't 
specify.  I can't think why I wouldn't want to run the slow ones without 
the fast ones, but if I did, it's not too hard to figure out a scheme 
that runs fast by default, slow when requested, and both if you request 
that instead.

            

      
      
      
    

        
Yes, do that as described above.

There are a

            

      
      
      
    

        
There is such a mechanism, and I've just described it (and not for the 
first time; it's also described in WRE).  I think the problem is that 
you and Spencer are looking for something that's more complicated.  It 
doesn't need to be complicated.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
On 2020-12-12 19:50, Duncan Murdoch wrote:

            

      
      
      
    

        
I want to put all the tests of a particular function in the 
"\examples" section.  If some things are too pedantic to show to a user, 
I can put them in "\dontshow".  If they run too long for CRAN, I wrap 
them in "if(!fda::CRAN()){...}", as I previously noted.


	  Putting slow tests in a "slowtest" directory to me violates a 
sensible rule of documentation, because it makes it harder to think 
about how complete a test suite is.


	  I probably should not broaden this discussion to include "\dontrun", 
but I will:  I think any example in "\dontrun" should be made to work 
and wrapped in something like "if(!fda::CRAN()){...}" if you don't want 
it to be run on CRAN, where you don't care if it breaks or not.  I've 
read too many books with examples that didn't work!  The "fda" package 
has 76 reverse dependencies.  I think most of those are attributable to 
the quality of the fundamental ideas, but I'd like to think that some of 
them are because I insisted in included decent unit tests in the 
"\examples" -- AND because I insisted on make sure all but a couple of 
the examples in the book actually worked!


	  Thanks very much to everyone who has contributed to this thread.  I 
don't think we've reached a consensus, but we've had a good discussion 
and may eventually help improve package documentation and testing 
practices in the future.


	  Spencer