On 12/12/20 4:08 PM, Spencer Graves wrote:
Hi, Ben et al.: On 2020-12-12 13:43, Ben Bolker wrote: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.> testthat::on_cran Error: 'on_cran' is not an exported object from 'namespace:testthat'
on_cran() is intended to be used via testthat::skip_on_cran() (which is exported, unlike on_cran()).
Besides, on my Mac, I get: > testthat:::on_cran() [1] TRUEMy 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".
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.
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).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".
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.
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.SpencerOn 12/12/20 2:19 PM, Spencer Graves wrote: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:Thanks, Dirk Just to clarify--In my packages, candisc, heplots, vcdExtra I have mostly 2D graphic methods, but some 3D methods that usergl. I therefore put rgl into Suggests: Could I solve this by making rgl a Depends: ? -Michael -----Original Message----- From: Dirk Eddelbuettel <e...@debian.org> Sent: Saturday, December 12, 2020 12:46 PM To: Michael L Friendly <frien...@yorku.ca>Cc: r-package-devel@R-project.org; Prof Brian Ripley <rip...@stats.ox.ac.uk> Subject: Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionallyOn 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 NOTEif (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 | e...@debian.org ______________________________________________ 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-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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
