Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 2020-12-12 19:50, Duncan Murdoch wrote:
On 12/12/2020 6:01 p.m., Ben Bolker wrote:
On 12/12/20 5:50 PM, Duncan Murdoch wrote:
On 12/12/2020 4:08 p.m., 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'
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".
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.
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?
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 ?
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.
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.
Yes, do that as described above.
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 ...
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.
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
Duncan Murdoch
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 12/12/2020 6:01 p.m., Ben Bolker wrote: On 12/12/20 5:50 PM, Duncan Murdoch wrote: On 12/12/2020 4:08 p.m., 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' 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". 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. 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? 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 ? 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. 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. Yes, do that as described above. 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 ... 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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 12/12/20 5:53 PM, Duncan Murdoch wrote: On 12/12/2020 4:41 p.m., Ben Bolker wrote: 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] 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". 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. What's wrong with users setting NOT_CRAN on all non-CRAN testing pipelines? 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 ...) 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. 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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 12/12/20 5:50 PM, Duncan Murdoch wrote: On 12/12/2020 4:08 p.m., 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' 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". 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. 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? 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 ...) Duncan Murdoch __ 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
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 12/12/2020 4:41 p.m., Ben Bolker wrote: 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] 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". 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. 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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
On 12/12/2020 4:08 p.m., 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' 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". 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. 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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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] 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".
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.
Spencer
On 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 use
rgl. I therefore put rgl into Suggests:
Could I solve this by making rgl a Depends: ?
-Michael
-Original Message-
From: Dirk Eddelbuettel
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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")),
|
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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'
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".
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".
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
On 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 use
rgl. I therefore put rgl into Suggests:
Could I solve this by making rgl a Depends: ?
-Michael
-Original Message-
From: Dirk Eddelbuettel
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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:
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 use
rgl. I therefore put rgl into Suggests:
Could I solve this by making rgl a Depends: ?
-Michael
-Original Message-
From: Dirk Eddelbuettel
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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 | e...@debian.org
__
R-package-devel@r-project.org mailing
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
Hi Michael,
It should be fine to have rgl in Suggests, and to have the 3D graphics
functions that use rgl throw an error if rgl is absent. What's not fine
is having these errors triggered in the absence of rgl when examples are
run or vignettes are compiled.
Putting rgl into Depends rather than Suggests would make the problem
worse, because you couldn't then load your package without rgl.
So, as I believe a couple of others have suggested, wrap the problematic
examples in, e.g., if(requireNamespace("rgl")){}, and do something
similar in the vignettes.
I hope this helps,
John
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/
On 2020-12-12 1:40 p.m., 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 use
rgl. I therefore put rgl into Suggests:
Could I solve this by making rgl a Depends: ?
-Michael
-Original Message-
From: Dirk Eddelbuettel
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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 | 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
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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 use
rgl. I therefore put rgl into Suggests:
Could I solve this by making rgl a Depends: ?
-Michael
-Original Message-
From: Dirk Eddelbuettel
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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 | 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
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly
Cc: r-package-devel@R-project.org; Prof Brian Ripley
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 | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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:
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 StreetWeb: http://www.datavis.ca | @datavisFriendly
Toronto, ONT M3J 1P3 CANADA
[[alternative HTML version deleted]]
__
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
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
Examples should use dontrun to avoid calling functions that call stop.
On December 12, 2020 8:24:50 AM PST, 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?
>
>
>
>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 StreetWeb: http://www.datavis.ca | @datavisFriendly
>Toronto, ONT M3J 1P3 CANADA
>
>
> [[alternative HTML version deleted]]
--
Sent from my phone. Please excuse my brevity.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
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 | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] First time CRAN package submission
Hi all,
I am trying to submit my first CRAN package, but I am having problems to
reproduce and correct all the issues that have been been reported by the
first failed attempt.
The package has quite a significant amount of Fortran 2003 code, and few
lines of C to link with R.
I hope some of you might give me some insight on how to correct them. I
will list the errors here below.
Relatively to the Windows test it has been reported to the following.
* installing *source* package 'modello' ...
> ** using staged installation
> ** libs *** arch - i386
> d:/Compiler/rtools40/mingw32/bin/gcc -I"D:/RCompile/recent/R/include"
> -DNDEBUG -I"d:/Compiler/gcc-4.9.3/local330/include" -pedantic -O2 -Wall
> -std=gnu99 -mfpmath=sse -msse2 -mstackrealign -c Rfuns.c -o Rfuns.o
> Rfuns.c: In function 'r__gamma':
> Rfuns.c:87:9: warning: implicit declaration of function 'gamma'
> [-Wimplicit-function-declaration]
> return(gamma(a[0]));
> ^
> Rfuns.c:87:9: warning: incompatible implicit declaration of built-in
> function 'gamma'
> d:/Compiler/rtools40/mingw32/bin/gcc -I"D:/RCompile/recent/R/include"
> -DNDEBUG -I"d:/Compiler/gcc-4.9.3/local330/include" -pedantic -O2 -Wall
> -std=gnu99 -mfpmath=sse -msse2 -mstackrealign -c Rinterfaces.c -o
> Rinterfaces.o
> d:/Compiler/rtools40/mingw32/bin/gfortran -fno-optimize-sibling-calls
> -fopenmp -L"D:/RCompile/recent/R/bin/i386" -lRlapack
> -L"D:/RCompile/recent/R/bin/i386" -lRblas -lgfortran -lm -lquadmath
> -pedantic -O2 -mfpmath=sse -msse2 -mstackrealign -c dataio.f95 -o dataio.o
> dataio.f95:2:6: use env
> 1
> Fatal Error: Can't open module file 'env.mod' for reading at (1): No such
> file or directory
> compilation terminated.
> make: *** [D:/RCompile/recent/R/etc/i386/Makeconf:263: dataio.o] Error 1
> ERROR: compilation failed for package 'modello'
> * removing 'd:/RCompile/CRANincoming/R-devel/lib/modello'
The warning "implicit declaration of function 'gamma'
[-Wimplicit-function-declaration]", refers to the fact that I am
calling the "gamma" function from Rmath.h in the following code block.
#include
> #include
> ...
> //** Gamma function
> double r__gamma (double *a) {
> /*
> * DOC
> * Wrapper to rhe R function gamma, calculationg the gamma function of a
> real number.
> * VARIABLES
> * in/out
> * a: a real number
> */
> //_MAIN_
> return(gamma(a[0]));
> }
The fatal error, refers to the fact the compiler cannot find the
env.mod module, but the Makefile is correctly defined.
Relatively to the Debian test, the following warning is what is making
to fail the submission.
* checking whether package ‘modello’ can be installed ... [32s/32s] WARNING
> Found the following significant warnings:
> Warning: Type specified for intrinsic function ‘size’ at (1) is ignored
> [-Wsurprising]
> Warning: ‘__var_1_fcn.offset’ is used uninitialized in this function
> [-Wuninitialized]
> Warning: ‘__var_2_fcn.offset’ is used uninitialized in this function
> [-Wuninitialized]
I have fixed the two warning due to uninitialized variables. However I
cannot reproduce the warning "Type specified for intrinsic function
‘size’ at (1) is ignored [-Wsurprising]" and I do not know how to fix
it. Googling a bit I understand it could be false positive (e.g.
https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg537501.html)
I would be very glad if anyone could give me advice on how to fix
these issues. Thanks in advance.
Regards,
Filippo
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
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 StreetWeb: http://www.datavis.ca | @datavisFriendly
Toronto, ONT M3J 1P3 CANADA
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
