[Rd] Suggested dependencies in context of R CMD check
Dear R team, Are suggested dependencies mandatory in context of `R CMD check` when using env var `_R_CHECK_FORCE_SUGGESTS_=FALSE`? Suggested dependencies are nice because are optional. But that feature often isn't valid when trying to run `R CMD check` on them. I would like to use `export _R_CHECK_FORCE_SUGGESTS_=FALSE`, which according to the comment in `tools/R/check.R`: > 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. should be sufficient to run *check* process without installing suggested deps. If it is not true, then how to differentiate the suggested packages which are optional from those mandatory? It would be helpful to have kind of `vignetteBuilder` DESCRIPTION field called `testChecker`, so DESCRIPTION file could precisely manage packages dependencies. That way batch checking packages would be easier, as required dep metadata would be at hand in description file. Batch checking pkgs with all their suggests will simply result into testing whole CRAN. In a single package it can be handled with `if (requireNamespace(.)) test_package(.)` for `testthat` and `knitr`, also with mocking up `.Rout` files. But I'm interested into canonical design of a suggested package and `_R_CHECK_FORCE_SUGGESTS_` env var. Is there any R core dev team recommendation/suggestion on that? and don't you thing new field `testChecker` in DESCRIPTION could help for batch checking pkgs? Installing all suggested packages of all reverse dependencies doesn't scale. Jan Gorecki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
Hi, Apologies for breaking the threading on this, I've only just signed up to the list and the last email was from September 2015. I've started to look into building R for Windows using MSYS2 as both the build environment and tools + libraries provider (where possible). I've managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 GCC: gcc.exe (Rev1, Built by MSYS2 project) 5.3.1 20160228 I've attached two patches that I needed, described below. I hope this is the appropriate place and way to suggest patches. Comments for improvements are very welcome. 0005-Win32-Extend-sqrt-NA_real_-hack-to-all-GCC-versions.patch Removes the __GNUC__ <= 4 for Windows ISNAN R_sqrt hack and doesn't replace it with any version check since I don't see any reason to second-guess when it might be fixed. When it is fixed in MinGW-w64 we can just remove the hack and be happy (I would hope to be able to get round to this in the next few months). 0006-Win32-GCC-5.3-Fix-ISNAN-int-emits-UD2-insn.patch The reason that boxplot.stats() was crashing was because when isnan() is called with an int it emits a UD2 instruction to force a crash, so let us just cast the input value to a double to prevent that. The code for this can be seen here: https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/math.h#L612-L622 -- Best regards, Ray Donnelly, Continuum Analytics Inc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On 03/04/2016 9:44 PM, Ray Donnelly wrote: Hi, Apologies for breaking the threading on this, I've only just signed up to the list and the last email was from September 2015. I've started to look into building R for Windows using MSYS2 as both the build environment and tools + libraries provider (where possible). I've managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 GCC: gcc.exe (Rev1, Built by MSYS2 project) 5.3.1 20160228 I've attached two patches that I needed, described below. I hope this is the appropriate place and way to suggest patches. Comments for improvements are very welcome. There were no patches attached, just the link to the mingw-w64 project on Github. Generally the way to produce patches for R is to use svn diff on a checked out working copy of the trunk. On Windows, Tortoisesvn makes this really simple. Then the patch will include information about the revision it's based on. You then upload it to bugs.r-project.org, along with a description of the problem it solves, and mark it as a bug fix or enhancement request. 0005-Win32-Extend-sqrt-NA_real_-hack-to-all-GCC-versions.patch Removes the __GNUC__ <= 4 for Windows ISNAN R_sqrt hack and doesn't replace it with any version check since I don't see any reason to second-guess when it might be fixed. When it is fixed in MinGW-w64 we can just remove the hack and be happy (I would hope to be able to get round to this in the next few months). I can see increasing the version limit when we commit to gcc 5.x, but I think the point of the test is to remind users of new versions to remind the developers that they have a bug. If we work around it forever, it will never get fixed. 0006-Win32-GCC-5.3-Fix-ISNAN-int-emits-UD2-insn.patch The reason that boxplot.stats() was crashing was because when isnan() is called with an int it emits a UD2 instruction to force a crash, so let us just cast the input value to a double to prevent that. The code for this can be seen here: https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/math.h#L612-L622 This one I can't guess at without seeing the patch. Duncan Murdoch -- Best regards, Ray Donnelly, Continuum Analytics Inc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: > Dear R team, > > Are suggested dependencies mandatory in context of `R CMD check` when > using env var `_R_CHECK_FORCE_SUGGESTS_=FALSE`? > > Suggested dependencies are nice because are optional. > But that feature often isn't valid when trying to run `R CMD check` on them. > I would like to use `export _R_CHECK_FORCE_SUGGESTS_=FALSE`, which > according to the comment in `tools/R/check.R`: > >> 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. > > should be sufficient to run *check* process without installing suggested deps. > If it is not true, then how to differentiate the suggested packages > which are optional from those mandatory? > It would be helpful to have kind of `vignetteBuilder` DESCRIPTION > field called `testChecker`, so DESCRIPTION file could precisely manage > packages dependencies. > That way batch checking packages would be easier, as required dep > metadata would be at hand in description file. Batch checking pkgs > with all their suggests will simply result into testing whole CRAN. > > In a single package it can be handled with `if (requireNamespace(.)) > test_package(.)` for `testthat` and `knitr`, also with mocking up > `.Rout` files. > > But I'm interested into canonical design of a suggested package and > `_R_CHECK_FORCE_SUGGESTS_` env var. > Is there any R core dev team recommendation/suggestion on that? and > don't you thing new field `testChecker` in DESCRIPTION could help for > batch checking pkgs? Installing all suggested packages of all reverse > dependencies doesn't scale. In principle, I believe a package should pass R CMD check if no suggested packages are installed. However, since this is not currently automatically checked, many packages will fail to cleanly pass R CMD check if suggested packages are missing. In my experience, it's much easier to simply install all dependencies of your reverse dependencies (although this is obviously much easier when you're using a platform with binary packages available from CRAN). I routinely do this for hundreds to thousands of packages. Hadley -- http://hadley.nz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
Jan and Hadley, There's also the issue of tests, vignettes, or examples requiring Suggested packages (one of the core applications of Suggests, in fact). These are all checked by R CMD check, so to ensure any package which should pass check would do so without suggested packages installed would require turning all of those checks off, which takes quite a few of the teeth out of R CMD check (and thus the assurances granted by knowing a package passes it). AFAIK (without going off and checking right now) you /could/ force R CMD check to do this now with a combination of options, though, if that's really what you want (which would allow your package to pass when _R_CHECK_FORCE_SUGGESTS_ is set to false). ~G On Mon, Apr 4, 2016 at 7:25 AM, Hadley Wickham wrote: > On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: > > Dear R team, > > > > Are suggested dependencies mandatory in context of `R CMD check` when > > using env var `_R_CHECK_FORCE_SUGGESTS_=FALSE`? > > > > Suggested dependencies are nice because are optional. > > But that feature often isn't valid when trying to run `R CMD check` on > them. > > I would like to use `export _R_CHECK_FORCE_SUGGESTS_=FALSE`, which > > according to the comment in `tools/R/check.R`: > > > >> 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. > > > > should be sufficient to run *check* process without installing suggested > deps. > > If it is not true, then how to differentiate the suggested packages > > which are optional from those mandatory? > > It would be helpful to have kind of `vignetteBuilder` DESCRIPTION > > field called `testChecker`, so DESCRIPTION file could precisely manage > > packages dependencies. > > That way batch checking packages would be easier, as required dep > > metadata would be at hand in description file. Batch checking pkgs > > with all their suggests will simply result into testing whole CRAN. > > > > In a single package it can be handled with `if (requireNamespace(.)) > > test_package(.)` for `testthat` and `knitr`, also with mocking up > > `.Rout` files. > > > > But I'm interested into canonical design of a suggested package and > > `_R_CHECK_FORCE_SUGGESTS_` env var. > > Is there any R core dev team recommendation/suggestion on that? and > > don't you thing new field `testChecker` in DESCRIPTION could help for > > batch checking pkgs? Installing all suggested packages of all reverse > > dependencies doesn't scale. > > In principle, I believe a package should pass R CMD check if no > suggested packages are installed. However, since this is not currently > automatically checked, many packages will fail to cleanly pass R CMD > check if suggested packages are missing. In my experience, it's much > easier to simply install all dependencies of your reverse dependencies > (although this is obviously much easier when you're using a platform > with binary packages available from CRAN). I routinely do this for > hundreds to thousands of packages. > > Hadley > > -- > http://hadley.nz > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Understanding POSIXct creation on different OSes.
Hello,
Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619
we would like to clarify if this is the right behaviour, and if so,
the rationale behind it.
Here's the summary (thanks to Dirk and Joshua):
Sys.setenv("TZ"="America/Chicago")
dates = as.Date("2016-03-02") + (0:3)*7 # four Wednesdays
# [1] "2016-03-02" "2016-03-09" "2016-03-16" "2016-03-23"
# on OS X and Windows 10 -- expected result
as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
# [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"
# On Linux (tested on Ubuntu 14.04) -- not as expected
as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
# [1] "2016-03-02 00:00:00 CST" "2016-03-09 00:00:00 CST" "2016-03-16
01:00:00 CDT" "2016-03-23 01:00:00 CDT"
# 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected
# since dates don't have timezones, as pointed out by @JoshuaUlrich under
# issue #1619.
lt = as.POSIXlt(dates)
lt$isdst
# [1] 0 0 0 0
# However, as Dirk points out, setting isdst to -1 on Ubuntu returns
expected results
lt$isdst = -1
as.POSIXct(lt, tz = "America/Chicago")
# [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"
# Note that setting isdst to -1 on OS X / Windows has no effect, i.e.,
the result is always as expected.
As Dirk points out, from ?POSIXlt:
"Where possible the platform limits are detected, and outside the
limits we use our own C code. This uses the offset from GMT in
use either for 1902 (when there was no DST) or that predicted for
one of 2030 to 2037 (chosen so that the likely DST transition days
are Sundays), and uses the alternate (daylight-saving) time zone
only if ‘isdst’ is positive or (if ‘-1’) if DST was predicted to
be in operation in the 2030s on that day."
It's not clear what this exactly means, and if it is related to the
behaviour shown above. It'd be nice to know if a) this behaviour of
non-identical result is as expected, and if so, b) can we rely on
setting 'isdst' to -1 returning the expected result always?
Thank you,
Arun.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
On 4 April 2016 at 07:25, Hadley Wickham wrote: | On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: | | In principle, I believe a package should pass R CMD check if no | suggested packages are installed. However, since this is not currently The relevant manual says The 'Suggests' field uses the same syntax as 'Depends' and lists packages that are not necessarily needed. This includes packages used only in examples, tests or vignettes (*note Writing package vignettes::), and packages loaded in the body of functions. E.g., suppose an example(1) from package *foo* uses a dataset from package *bar*. Then it is not necessary to have *bar* use *foo* unless one wants to execute all the examples/tests/vignettes: it is useful to have *bar*, but not necessary. Version requirements can be specified, and will be used by 'R CMD check'. and later * All packages that are needed(2) to successfully run 'R CMD check' on the package must be listed in one of 'Depends' or 'Suggests' or 'Imports'. Packages used to run examples or tests conditionally (e.g. _via_ 'if(require(PKGNAME))') should be listed in 'Suggests' or 'Enhances'. (This allows checkers to ensure that all the packages needed for a complete check are installed.) | automatically checked, many packages will fail to cleanly pass R CMD | check if suggested packages are missing. I consider that to be a bug in those 'many packages'. It essentially takes away the usefulness of having a Suggests: to provide a more fine-grained dependency graph. So I am with Jan here. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
On 04/04/2016 1:35 PM, Dirk Eddelbuettel wrote: On 4 April 2016 at 07:25, Hadley Wickham wrote: | On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: | | In principle, I believe a package should pass R CMD check if no | suggested packages are installed. However, since this is not currently The relevant manual says The 'Suggests' field uses the same syntax as 'Depends' and lists packages that are not necessarily needed. This includes packages used only in examples, tests or vignettes (*note Writing package vignettes::), and packages loaded in the body of functions. E.g., suppose an example(1) from package *foo* uses a dataset from package *bar*. Then it is not necessary to have *bar* use *foo* unless one wants to execute all the examples/tests/vignettes: it is useful to have *bar*, but not necessary. Version requirements can be specified, and will be used by 'R CMD check'. and later * All packages that are needed(2) to successfully run 'R CMD check' on the package must be listed in one of 'Depends' or 'Suggests' or 'Imports'. Packages used to run examples or tests conditionally (e.g. _via_ 'if(require(PKGNAME))') should be listed in 'Suggests' or 'Enhances'. (This allows checkers to ensure that all the packages needed for a complete check are installed.) | automatically checked, many packages will fail to cleanly pass R CMD | check if suggested packages are missing. I consider that to be a bug in those 'many packages'. It essentially takes away the usefulness of having a Suggests: to provide a more fine-grained dependency graph. So I am with Jan here. I think I agree with Jan, but not for the reason you state. Suggests is useful even if "R CMD check" treats it as Depends, because most users never need to run "R CMD check". It allows them to use a subset of the functionality of a package without installing tons of dependencies. I agree that packages that fail on examples when Suggested packages are missing are broken. (Using if (require()) to skip particular examples isn't failing.) It would be useful to be able to detect failure; I don't think that's easy now with "R CMD check". That's why you should be able to run it with Suggested packages missing. The ideal situation would be to be able to run all possible combinations of missing Suggested packages, but that's probably far too slow to be a default. BTW, I'm not completely sure it needs to be possible to run vignettes without the Suggested packages they need. Vignettes are allowed to depend on things that aren't available to all users, and adding all the require() tests could make them less clear. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On Sun, Apr 3, 2016 at 6:44 PM, Ray Donnelly wrote: > I've started to look into building R for Windows using MSYS2 as both the > build environment and tools + libraries provider (where possible). Thanks for your reply, and for the patches. Last time I had a look at this (a few months ago) another problem was that mingw-w64 v4 was giving different numeric output for some of the tests in r-base. If I recall correctly, some eigen vectors had their direction flipped (negative values became positive and vice versa). Did you notice anything of this kind when running 'make check' and 'make check recommended' ? It is important to us that numeric results are reproducible between versions of R. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] debug/recover/.Internal
I was surprised by difference between using options(error=browser) and
options(error=recover) when handling an error from sys.frame that I
assume is related to the fact that the error is thrown from the
.Internal and the 'which' parameter to the closure isn't available.
> options(error=browser)
> f <- function() sys.frame(-3)
> f()
Error in sys.frame(-3) : not that many frames on the stack
Called from: sys.frame(-3)
Browse[1]> where
where 1 at #1: sys.frame(-3)
where 2: f()
Browse[1]> print(which)
function (x, arr.ind = FALSE, useNames = TRUE)
{
wh <- .Internal(which(x))
if (arr.ind && !is.null(d <- dim(x)))
arrayInd(wh, d, dimnames(x), useNames = useNames)
else wh
}
Whereas:
> options(error=recover)
> f()
Error in sys.frame(-3) : not that many frames on the stack
Enter a frame number, or 0 to exit
1: f()
2: #1: sys.frame(-3)
Selection: 2
Called from: top level
Browse[1]> print(which)
[1] -3
Browse[1]>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On Mon, Apr 4, 2016 at 12:29 PM, Duncan Murdoch wrote: > On 03/04/2016 9:44 PM, Ray Donnelly wrote: > >> Hi, >> >> Apologies for breaking the threading on this, I've only just signed up to >> the list and the last email was from September 2015. >> >> I've started to look into building R for Windows using MSYS2 as both the >> build environment and tools + libraries provider (where possible). I've >> managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 >> GCC: >> gcc.exe (Rev1, Built by MSYS2 project) 5.3.1 20160228 >> >> I've attached two patches that I needed, described below. I hope this is >> the appropriate place and way to suggest patches. Comments for >> improvements >> are very welcome. >> > > There were no patches attached, just the link to the mingw-w64 project on > Github. > Ah, that's strange, they must have got stripped. > > Generally the way to produce patches for R is to use svn diff on a checked > out working copy of the trunk. On Windows, Tortoisesvn makes this really > simple. Then the patch will include information about the revision it's > based on. You then upload it to bugs.r-project.org, along with a > description of the problem it solves, and mark it as a bug fix or > enhancement request. Ok, I had used diffutils' diff -urN on the 3.2.4-revised release to generate them. > > >> 0005-Win32-Extend-sqrt-NA_real_-hack-to-all-GCC-versions.patch >> Removes the __GNUC__ <= 4 for Windows ISNAN R_sqrt hack and doesn't >> replace >> it with any version check since I don't see any reason to second-guess >> when >> it might be fixed. When it is fixed in MinGW-w64 we can just remove the >> hack and be happy (I would hope to be able to get round to this in the >> next >> few months). >> > > I can see increasing the version limit when we commit to gcc 5.x, but I > think the point of the test is to remind users of new versions to remind > the developers that they have a bug. If we work around it forever, it will > never get fixed. OK. Am I right in thinking that many GNU/Linux distributions already build R with GCC > 4? The bug here lies with MinGW-w64 and not with GCC. > > >> 0006-Win32-GCC-5.3-Fix-ISNAN-int-emits-UD2-insn.patch >> The reason that boxplot.stats() was crashing was because when isnan() is >> called with an int it emits a UD2 instruction to force a crash, so let us >> just cast the input value to a double to prevent that. The code for this >> can be seen here: >> >> https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/math.h#L612-L622 >> > > This one I can't guess at without seeing the patch. > Both patches modified the exact same lines in eval.c, so I will need to regenerate it if we are dropping the first patch (and also generate it with svn diff), but I may as well inline it since it's so simple: --- src/main/eval.c2016-04-03 19:46:51.025442100 +0100 +++ src/main/eval.c.new2016-04-03 19:46:48.279325900 +0100 @@ -3624,7 +3624,7 @@ toolchain or in our expectations, but these defines attempt to work around this. */ #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) -# define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) +# define R_sqrt(x) (ISNAN((double)x) ? x : sqrt(x)) #else # define R_sqrt sqrt #endif But, we should fix this in MinGW-w64. It's returning a different +/-NaN from the input NaN in contrast to all the other platforms that R runs on, as far as I can gather. In that case, I've proposed a patch to address this issue and if and when this makes it into a release I will send another patch to R's Bugzilla to avoid this hack altogether if using that release or a later version, and otherwise to use a combination of the two patches I supplied earlier. > Duncan Murdoch > > > >> -- >> >> Best regards, >> >> Ray Donnelly, >> >> Continuum Analytics Inc. >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On Mon, Apr 4, 2016 at 7:39 PM, Jeroen Ooms wrote: > On Sun, Apr 3, 2016 at 6:44 PM, Ray Donnelly > wrote: > > I've started to look into building R for Windows using MSYS2 as both the > > build environment and tools + libraries provider (where possible). > > Thanks for your reply, and for the patches. > No problem. > Last time I had a look at this (a few months ago) another problem was > that mingw-w64 v4 was giving different numeric output for some of the > tests in r-base. If I recall correctly, some eigen vectors had their > direction flipped (negative values became positive and vice versa). > Did you notice anything of this kind when running 'make check' and > 'make check recommended' ? It is important to us that numeric results > are reproducible between versions of R. > I have not seen make check fail with any reports of eigenvector flip. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
>If I recall correctly, some eigen vectors had their >direction flipped (negative values became positive and vice versa). >Did you notice anything of this kind when running 'make check' and >'make check recommended' ? It is important to us that numeric results >are reproducible between versions of R. I think that any code that depends on the direction of an eigenvector should be considered broken. It is too bad that eigen's output does not have a class so that an all.equal method that know that the vector direction is not relevant could be written for it Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Apr 4, 2016 at 11:39 AM, Jeroen Ooms wrote: > On Sun, Apr 3, 2016 at 6:44 PM, Ray Donnelly > wrote: > > I've started to look into building R for Windows using MSYS2 as both the > > build environment and tools + libraries provider (where possible). > > Thanks for your reply, and for the patches. > > Last time I had a look at this (a few months ago) another problem was > that mingw-w64 v4 was giving different numeric output for some of the > tests in r-base. If I recall correctly, some eigen vectors had their > direction flipped (negative values became positive and vice versa). > Did you notice anything of this kind when running 'make check' and > 'make check recommended' ? It is important to us that numeric results > are reproducible between versions of R. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
On 04/04/2016 01:56 PM, Duncan Murdoch wrote: On 04/04/2016 1:35 PM, Dirk Eddelbuettel wrote: On 4 April 2016 at 07:25, Hadley Wickham wrote: | On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: | | In principle, I believe a package should pass R CMD check if no | suggested packages are installed. However, since this is not currently The relevant manual says The 'Suggests' field uses the same syntax as 'Depends' and lists packages that are not necessarily needed. This includes packages used only in examples, tests or vignettes (*note Writing package vignettes::), and packages loaded in the body of functions. E.g., suppose an example(1) from package *foo* uses a dataset from package *bar*. Then it is not necessary to have *bar* use *foo* unless one wants to execute all the examples/tests/vignettes: it is useful to have *bar*, but not necessary. Version requirements can be specified, and will be used by 'R CMD check'. and later * All packages that are needed(2) to successfully run 'R CMD check' on the package must be listed in one of 'Depends' or 'Suggests' or 'Imports'. Packages used to run examples or tests conditionally (e.g. _via_ 'if(require(PKGNAME))') should be listed in 'Suggests' or 'Enhances'. (This allows checkers to ensure that all the packages needed for a complete check are installed.) | automatically checked, many packages will fail to cleanly pass R CMD | check if suggested packages are missing. I consider that to be a bug in those 'many packages'. It essentially takes away the usefulness of having a Suggests: to provide a more fine-grained dependency graph. So I am with Jan here. I think I agree with Jan, but not for the reason you state. Suggests is useful even if "R CMD check" treats it as Depends, because most users never need to run "R CMD check". It allows them to use a subset of the functionality of a package without installing tons of dependencies. I agree that packages that fail on examples when Suggested packages are missing are broken. (Using if (require()) to skip particular examples isn't failing.) It would be useful to be able to detect failure; I don't think that's easy now with "R CMD check". That's why you should be able to run it with Suggested packages missing. Perhaps I'm confused, it would not be the first time, but I have the impression that some/all? of you are arguing for a different philosophy around R CMD check and Suggests/Depends. But the current design is not broken, it is working the way it has been advertised for many years now. It provides a fine-grained dependency graph for end users, not developers and testers. Being able to suggest packages for use in testing, when they are not needed for regular use is a good thing. A package failing R CMD check when the suggested packages are not available is not a bug, it is a feature following the rules as they have been designed. If you want to check a package then you need to install things that are needed to check it. If R CMD check skipped testing because suggested packages were not available then you will have many packages not being tested properly, that is, lots of broken packages passing R CMD check. (I've done this to myself sometimes using if(require()).) There are situations where some testing needs to be skipped, for example, license requirements and special databases, but this needs to be done carefully, and my impression is that if(require()) provides most of what is necessary, sometimes along with environment variables. Perhaps this is not elegant, but it does work and is not difficult. The ideal situation would be to be able to run all possible combinations of missing Suggested packages, but that's probably far too slow to be a default. But how do you decide pass/fail when you do this? I think it will only pass when all the suggested packages are available? Paul Gilbert BTW, I'm not completely sure it needs to be possible to run vignettes without the Suggested packages they need. Vignettes are allowed to depend on things that aren't available to all users, and adding all the require() tests could make them less clear. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested dependencies in context of R CMD check
On 04/04/2016 7:12 PM, Paul Gilbert wrote: On 04/04/2016 01:56 PM, Duncan Murdoch wrote: On 04/04/2016 1:35 PM, Dirk Eddelbuettel wrote: On 4 April 2016 at 07:25, Hadley Wickham wrote: | On Sat, Apr 2, 2016 at 5:33 AM, Jan Górecki wrote: | | In principle, I believe a package should pass R CMD check if no | suggested packages are installed. However, since this is not currently The relevant manual says The 'Suggests' field uses the same syntax as 'Depends' and lists packages that are not necessarily needed. This includes packages used only in examples, tests or vignettes (*note Writing package vignettes::), and packages loaded in the body of functions. E.g., suppose an example(1) from package *foo* uses a dataset from package *bar*. Then it is not necessary to have *bar* use *foo* unless one wants to execute all the examples/tests/vignettes: it is useful to have *bar*, but not necessary. Version requirements can be specified, and will be used by 'R CMD check'. and later * All packages that are needed(2) to successfully run 'R CMD check' on the package must be listed in one of 'Depends' or 'Suggests' or 'Imports'. Packages used to run examples or tests conditionally (e.g. _via_ 'if(require(PKGNAME))') should be listed in 'Suggests' or 'Enhances'. (This allows checkers to ensure that all the packages needed for a complete check are installed.) | automatically checked, many packages will fail to cleanly pass R CMD | check if suggested packages are missing. I consider that to be a bug in those 'many packages'. It essentially takes away the usefulness of having a Suggests: to provide a more fine-grained dependency graph. So I am with Jan here. I think I agree with Jan, but not for the reason you state. Suggests is useful even if "R CMD check" treats it as Depends, because most users never need to run "R CMD check". It allows them to use a subset of the functionality of a package without installing tons of dependencies. I agree that packages that fail on examples when Suggested packages are missing are broken. (Using if (require()) to skip particular examples isn't failing.) It would be useful to be able to detect failure; I don't think that's easy now with "R CMD check". That's why you should be able to run it with Suggested packages missing. Perhaps I'm confused, it would not be the first time, but I have the impression that some/all? of you are arguing for a different philosophy around R CMD check and Suggests/Depends. But the current design is not broken, it is working the way it has been advertised for many years now. It provides a fine-grained dependency graph for end users, not developers and testers. Being able to suggest packages for use in testing, when they are not needed for regular use is a good thing. A package failing R CMD check when the suggested packages are not available is not a bug, it is a feature following the rules as they have been designed. If you want to check a package then you need to install things that are needed to check it. If R CMD check skipped testing because suggested packages were not available then you will have many packages not being tested properly, that is, lots of broken packages passing R CMD check. (I've done this to myself sometimes using if(require()).) There are situations where some testing needs to be skipped, for example, license requirements and special databases, but this needs to be done carefully, and my impression is that if(require()) provides most of what is necessary, sometimes along with environment variables. Perhaps this is not elegant, but it does work and is not difficult. The ideal situation would be to be able to run all possible combinations of missing Suggested packages, but that's probably far too slow to be a default. But how do you decide pass/fail when you do this? I think it will only pass when all the suggested packages are available? Supposing all dependencies are available, there are several ways to decide on pass vs fail. - You fail if your examples generate an error. - If you have saved example output, you fail if it doesn't match the old output. - You fail if your tests generate an error, or have different output than the optional saved output. So what if some Suggested files are not available during testing? The "fail on error" rule would be identical if the Suggested packages were missing. Output of tests and examples will likely change, so if it were possible to test without Suggested packages, you'd need a way to indicate what changes are allowed. (But most packages don't save test results and don't save example output anyway.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
