I just received a bug report about the rgl package: it claims to depend on R >= 3.2.0, but actually uses the hcl.colors() function that was introduced in R 3.6.0, so fails to install. (This dependence was introduced while I had the dependence stated as R >= 4.0.0 for a while, until I tried to help people stuck on old releases; I fixed some of the 4.0.0 needs, but missed this one.) So of course what I should have done was to run the checks on R 3.2.0 (and maybe intermediate versions) to confirm it works, but I didn't try that before releasing to CRAN. I've just finished installing a copy of R 3.2.0 and testing my fix, so I think things are fine now. This took some work; some of the packages used by the current rgl didn't exist when R 3.2.0 was current, so no binaries exist for them; installing the tools for binary builds takes time, etc. So finally, my question: what is the recommended way to handle tests of new packages on old R versions? Do docker or other images exist that are already set up and ready to go? Duncan Murdoch
[R-pkg-devel] Testing on old R versions
14 messages · Duncan Murdoch, Neal Richardson, Nathan Watson-Haigh +4 more
I've used the https://hub.docker.com/r/rstudio/r-base images for this, and they appear to go back to R 3.1. Likewise https://hub.docker.com/r/rocker/r-ver. The latter uses MRAN to install packages from a CRAN snapshot corresponding to the release, so that should also help with dependencies. Neal On Thu, Jan 28, 2021 at 7:06 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
I just received a bug report about the rgl package: it claims to depend on R >= 3.2.0, but actually uses the hcl.colors() function that was introduced in R 3.6.0, so fails to install. (This dependence was introduced while I had the dependence stated as R >= 4.0.0 for a while, until I tried to help people stuck on old releases; I fixed some of the 4.0.0 needs, but missed this one.) So of course what I should have done was to run the checks on R 3.2.0 (and maybe intermediate versions) to confirm it works, but I didn't try that before releasing to CRAN. I've just finished installing a copy of R 3.2.0 and testing my fix, so I think things are fine now. This took some work; some of the packages used by the current rgl didn't exist when R 3.2.0 was current, so no binaries exist for them; installing the tools for binary builds takes time, etc. So finally, my question: what is the recommended way to handle tests of new packages on old R versions? Do docker or other images exist that are already set up and ready to go? Duncan Murdoch
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
The Rocker Project provides both rocker/r-ver (with package snapshotting) as well as the (much smaller, just R) rocker/r-base images which are then passed on to the Docker team to become the official r-base image. These go back to 3.1.3 with (almost if not all) interim releases, see https://hub.docker.com/_/r-base?tab=tags and just use, say, 'docker pull r-base:3.2.0' (Because they are available as these 'r-base' I initially didn't initially tag them at the rocker/r-base side so there tags only started at 3.6.3.) For the use case of testing rgl you may need to find the appropriate opengl libraries for the particular release. These r-base images are all Debian based, and Debian has a handy 'time machine' feature in snapshot.debian.org which also lets you pick dates to install .deb binaries from. That should make rgl testing easy in case you need older versions of the build dependencies. Dirk
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
I haven't tried it (yet), but perhaps using github actions CI you could specify an older version of R: https://github.com/r-lib/actions/tree/master/setup-r Sent from my Samsung Galaxy S10+. Get Outlook for Android<https://aka.ms/ghei36>
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Duncan Murdoch <murdoch.duncan at gmail.com>
Sent: Friday, January 29, 2021 1:35:40 AM
To: r-package-devel at r-project.org <r-package-devel at r-project.org>
Subject: [R-pkg-devel] Testing on old R versions
Sent: Friday, January 29, 2021 1:35:40 AM
To: r-package-devel at r-project.org <r-package-devel at r-project.org>
Subject: [R-pkg-devel] Testing on old R versions
I just received a bug report about the rgl package: it claims to depend on R >= 3.2.0, but actually uses the hcl.colors() function that was introduced in R 3.6.0, so fails to install. (This dependence was introduced while I had the dependence stated as R >= 4.0.0 for a while, until I tried to help people stuck on old releases; I fixed some of the 4.0.0 needs, but missed this one.) So of course what I should have done was to run the checks on R 3.2.0 (and maybe intermediate versions) to confirm it works, but I didn't try that before releasing to CRAN. I've just finished installing a copy of R 3.2.0 and testing my fix, so I think things are fine now. This took some work; some of the packages used by the current rgl didn't exist when R 3.2.0 was current, so no binaries exist for them; installing the tools for binary builds takes time, etc. So finally, my question: what is the recommended way to handle tests of new packages on old R versions? Do docker or other images exist that are already set up and ready to go? Duncan Murdoch ______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion. So far I haven't got it to work in 3.2.0; I probably won't put much effort into supporting that old version. But it's fine in 3.4.0 and 3.5.0, and I'm trying 3.3.0 now. Rocker rocks! P.S. rgl now installs in the basic r-base container, without adding additional libs. This is due to some config checks that let it run on a barebones machine: it can still produce WebGL output for a browser, it just can't show it on screen. Duncan Murdoch
On 28/01/2021 11:42 a.m., Dirk Eddelbuettel wrote:
The Rocker Project provides both rocker/r-ver (with package snapshotting) as
well as the (much smaller, just R) rocker/r-base images which are then passed
on to the Docker team to become the official r-base image.
These go back to 3.1.3 with (almost if not all) interim releases, see
https://hub.docker.com/_/r-base?tab=tags
and just use, say, 'docker pull r-base:3.2.0'
(Because they are available as these 'r-base' I initially didn't initially
tag them at the rocker/r-base side so there tags only started at 3.6.3.)
For the use case of testing rgl you may need to find the appropriate opengl
libraries for the particular release. These r-base images are all Debian
based, and Debian has a handy 'time machine' feature in snapshot.debian.org
which also lets you pick dates to install .deb binaries from. That should
make rgl testing easy in case you need older versions of the build
dependencies.
Dirk
On 28 January 2021 at 16:50, Duncan Murdoch wrote:
| Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion. | | So far I haven't got it to work in 3.2.0; I probably won't put much | effort into supporting that old version. But it's fine in 3.4.0 and | 3.5.0, and I'm trying 3.3.0 now. Rocker rocks! Thanks, I would have to agree here :) | P.S. rgl now installs in the basic r-base container, without adding | additional libs. This is due to some config checks that let it run on a | barebones machine: it can still produce WebGL output for a browser, it | just can't show it on screen. Most excellent, didn't know that part. Ping we off-list if you're interested in automating this, I also use these containers (or sometimes extensions with additional build-dependencies) to test builds in CI settings. Setting that can be pretty straightforward and self-contained. It's easiest to instrument when you don't even need other build dependencies. Dirk
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0). BTW, I find Singularity (https://github.com/hpcng/singularity/) more convenient to work with than Docker, e.g. you run as host $USER also "inside" the container, $PWD and your $HOME folder is automatically mounted, the built container is a single executable (just like any other software you run). Here's how you can use Rocker's r-base with Singularity on Linux (Ubuntu 18.04): # Download and build {host}$ cd /tmp {host}$ singularity build r-3.3.0.sif docker://r-base:3.3.0 {host}$ ls -l r-3.3.0.sif -rwxr-xr-x 1 hb hb 385630208 Jan 28 16:05 r-3.3.0.sif # Run as-is {host}$ ./r-3.3.0.sif R version 3.3.0 (2016-05-03) -- "Supposedly Educational" Copyright (C) 2016 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) ...
quit("no")
Comment: There's also a 'singularity {run,exec,eval} ...' similar to
'docker' which comes with more features but lots can be done without
it.
# Persistent package installs to host via custom R_LIBS_USER
{host}$ cd /tmp
{host}$ mkdir R-libs-3.3.0
{host}$ R_LIBS_USER=R-libs-3.3.0 ./r-3.3.0.sif
R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
...
.libPaths()[1]
[1] "/tmp/R-libs-test"
install.packages("rgl")
Installing package into ?/tmp/R-libs-test?
(as ?lib? is unspecified)
also installing the dependencies ?ps?, ?fs?, ?rappdirs?, ?processx?,
?Rcpp?, ?BH?, ?sass?, ?jquerylib?, ?callr?, ?yaml?, ?digest?,
?base64enc?, ?rlang?, ?evaluate?, ?highr?, ?markdown?, ?xfun?,
?httpuv?, ?mime?, ?xtable?, ?R6?, ?sourcetools?, ?later?, ?promises?,
?crayon?, ?fastmap?, ?withr?, ?commonmark?, ?glue?, ?bslib?, ?cachem?,
?ellipsis?, ?lifecycle?, ?lazyeval?, ?miniUI?, ?webshot?,
?htmlwidgets?, ?htmltools?, ?knitr?, ?jsonlite?, ?shiny?, ?crosstalk?,
?manipulateWidget?
...
** preparing package for lazy loading
Error : object ?hcl.colors? is not exported by 'namespace:grDevices'
ERROR: lazy loading failed for package ?rgl?
* removing ?/tmp/R-libs-3.3.0/rgl?
The downloaded source packages are in
?/tmp/hb/RtmpzBZ0FJ/downloaded_packages?
Warning message:
In install.packages("rgl") :
installation of package ?rgl? had non-zero exit status
str(rownames(installed.packages()))
chr [1:77] "base64enc" "BH" "bslib" "cachem" "callr" ...
quit("no")
# The packages are indeed installed to the host folder and survives restarts
{host}$ R_LIBS_USER=R-libs-3.3.0 ./r-3.3.0.sif
...
str(rownames(installed.packages()))
Named chr [1:77] "base64enc" "BH" "bslib" "cachem" "callr" ... - attr(*, "names")= chr [1:77] "" "" "" "" ... So, running R via Singularity is almost the same as running R directly on the host. /Henrik
On Thu, Jan 28, 2021 at 2:29 PM Dirk Eddelbuettel <edd at debian.org> wrote:
On 28 January 2021 at 16:50, Duncan Murdoch wrote: | Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion. | | So far I haven't got it to work in 3.2.0; I probably won't put much | effort into supporting that old version. But it's fine in 3.4.0 and | 3.5.0, and I'm trying 3.3.0 now. Rocker rocks! Thanks, I would have to agree here :) | P.S. rgl now installs in the basic r-base container, without adding | additional libs. This is due to some config checks that let it run on a | barebones machine: it can still produce WebGL output for a browser, it | just can't show it on screen. Most excellent, didn't know that part. Ping we off-list if you're interested in automating this, I also use these containers (or sometimes extensions with additional build-dependencies) to test builds in CI settings. Setting that can be pretty straightforward and self-contained. It's easiest to instrument when you don't even need other build dependencies. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Thanks, I'll try Singularity out. (I tried it, but got some weird game playing when I tried to do my first build. Strange.) By the way, I've been thinking of downgrading the magrittr dependency to Suggests. The only reason it is currently Imports is so that rgl can re-export the pipe operator, and users don't need library(magrittr) to use it. rgl itself never uses anything from magrittr, and will work just as well with the R-devel proposed pipe: but if I'm trying to support ancient R versions, I won't be able to use it for a few years. I've just tried this, and rgl still won't install in 3.2.0. I guess this is because some of the other dependencies import magrittr, and/or there are other post 3.2.0 needs. In any case, I'm not too worried about that ancient of a version. Duncan Murdoch
On 28/01/2021 7:27 p.m., Henrik Bengtsson wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0). BTW, I find Singularity (https://github.com/hpcng/singularity/) more convenient to work with than Docker, e.g. you run as host $USER also "inside" the container, $PWD and your $HOME folder is automatically mounted, the built container is a single executable (just like any other software you run). Here's how you can use Rocker's r-base with Singularity on Linux (Ubuntu 18.04): # Download and build {host}$ cd /tmp {host}$ singularity build r-3.3.0.sif docker://r-base:3.3.0 {host}$ ls -l r-3.3.0.sif -rwxr-xr-x 1 hb hb 385630208 Jan 28 16:05 r-3.3.0.sif # Run as-is {host}$ ./r-3.3.0.sif R version 3.3.0 (2016-05-03) -- "Supposedly Educational" Copyright (C) 2016 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) ...
quit("no")
Comment: There's also a 'singularity {run,exec,eval} ...' similar to
'docker' which comes with more features but lots can be done without
it.
# Persistent package installs to host via custom R_LIBS_USER
{host}$ cd /tmp
{host}$ mkdir R-libs-3.3.0
{host}$ R_LIBS_USER=R-libs-3.3.0 ./r-3.3.0.sif
R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
...
.libPaths()[1]
[1] "/tmp/R-libs-test"
install.packages("rgl")
Installing package into ?/tmp/R-libs-test?
(as ?lib? is unspecified)
also installing the dependencies ?ps?, ?fs?, ?rappdirs?, ?processx?,
?Rcpp?, ?BH?, ?sass?, ?jquerylib?, ?callr?, ?yaml?, ?digest?,
?base64enc?, ?rlang?, ?evaluate?, ?highr?, ?markdown?, ?xfun?,
?httpuv?, ?mime?, ?xtable?, ?R6?, ?sourcetools?, ?later?, ?promises?,
?crayon?, ?fastmap?, ?withr?, ?commonmark?, ?glue?, ?bslib?, ?cachem?,
?ellipsis?, ?lifecycle?, ?lazyeval?, ?miniUI?, ?webshot?,
?htmlwidgets?, ?htmltools?, ?knitr?, ?jsonlite?, ?shiny?, ?crosstalk?,
?manipulateWidget?
...
** preparing package for lazy loading
Error : object ?hcl.colors? is not exported by 'namespace:grDevices'
ERROR: lazy loading failed for package ?rgl?
* removing ?/tmp/R-libs-3.3.0/rgl?
The downloaded source packages are in
?/tmp/hb/RtmpzBZ0FJ/downloaded_packages?
Warning message:
In install.packages("rgl") :
installation of package ?rgl? had non-zero exit status
str(rownames(installed.packages()))
chr [1:77] "base64enc" "BH" "bslib" "cachem" "callr" ...
quit("no")
# The packages are indeed installed to the host folder and survives restarts
{host}$ R_LIBS_USER=R-libs-3.3.0 ./r-3.3.0.sif
...
str(rownames(installed.packages()))
Named chr [1:77] "base64enc" "BH" "bslib" "cachem" "callr" ... - attr(*, "names")= chr [1:77] "" "" "" "" ... So, running R via Singularity is almost the same as running R directly on the host. /Henrik On Thu, Jan 28, 2021 at 2:29 PM Dirk Eddelbuettel <edd at debian.org> wrote:
On 28 January 2021 at 16:50, Duncan Murdoch wrote: | Thanks Dirk, Neal and Nathan. I ended up going with Dirk's suggestion. | | So far I haven't got it to work in 3.2.0; I probably won't put much | effort into supporting that old version. But it's fine in 3.4.0 and | 3.5.0, and I'm trying 3.3.0 now. Rocker rocks! Thanks, I would have to agree here :) | P.S. rgl now installs in the basic r-base container, without adding | additional libs. This is due to some config checks that let it run on a | barebones machine: it can still produce WebGL output for a browser, it | just can't show it on screen. Most excellent, didn't know that part. Ping we off-list if you're interested in automating this, I also use these containers (or sometimes extensions with additional build-dependencies) to test builds in CI settings. Setting that can be pretty straightforward and self-contained. It's easiest to instrument when you don't even need other build dependencies. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson
<henrik.bengtsson at gmail.com> wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four versions of R: https://www.tidyverse.org/blog/2019/04/r-version-support/. We automatically run checks on all these R versions using GitHub actions. You can use the same config as us by running usethis::use_tidy_github_actions(). If you're already using GitHub, I'm pretty confident that this is the fastest/easiest way to check with older versions of R. Hadley
1 day later
I am trying out a modified version of the tidyverse actions, and it does seem to be going well. Just one question: rgl has a soft dependency on alphashape3d, and alphashape3d has a hard dependency on rgl. This means that I need to install in the order rgl hard dependencies rgl rgl soft dependencies Currently I'm using this code to do that: # First install rgl with minimal deps then the rest devtools::install() remotes::install_deps(dependencies = TRUE) but devtools seems unnecessarily heavy for this. Does remotes have a way to specify the install in the right order? Duncan Murdoch
On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four versions of R: https://www.tidyverse.org/blog/2019/04/r-version-support/. We automatically run checks on all these R versions using GitHub actions. You can use the same config as us by running usethis::use_tidy_github_actions(). If you're already using GitHub, I'm pretty confident that this is the fastest/easiest way to check with older versions of R. Hadley
On Sun, Jan 31, 2021 at 4:32 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
I am trying out a modified version of the tidyverse actions, and it does seem to be going well. Just one question: rgl has a soft dependency on alphashape3d, and alphashape3d has a hard dependency on rgl. This means that I need to install in the order rgl hard dependencies rgl rgl soft dependencies Currently I'm using this code to do that: # First install rgl with minimal deps then the rest devtools::install() remotes::install_deps(dependencies = TRUE) but devtools seems unnecessarily heavy for this. Does remotes have a way to specify the install in the right order?
I forget all the details here but instead of `devtools::install()`, I'm pretty sure you can just use `remotes::install_local()`. We also have an experimental workflow that uses pak (https://github.com/r-lib/actions/blob/master/examples/check-pak.yaml); and pak should know enough about the full dependency graph to install all dependencies in the correct order without additional work. This workflow (and pak) itself, is still a bit experimental but we've started to move the tidyverse workflows to use pak, and haven't had many problems recently. Hadley
Do you actually experience any problems, if you don't treat this case specially? AFAIR, in most cases this is not a problem in practice. remotes might install the CRAN version of rgl as the dependency of alphashape3d, but `R CMD check` will install and use the local copy of the rgl package for the check, anyway, so that does not matter much. More precisely, it would only matter if alphashape3d had some install time dependency on rgl, because at install time, it will use the CRAN rgl version. But this is pretty rare I think. If you still want to fix this, you can replace `remotes::install_deps()` with `remotes::install_local()` and then remotes will install the local package as well, not only its dependencies. Gabor On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
I am trying out a modified version of the tidyverse actions, and it does seem to be going well. Just one question: rgl has a soft dependency on alphashape3d, and alphashape3d has a hard dependency on rgl. This means that I need to install in the order rgl hard dependencies rgl rgl soft dependencies Currently I'm using this code to do that: # First install rgl with minimal deps then the rest devtools::install() remotes::install_deps(dependencies = TRUE) but devtools seems unnecessarily heavy for this. Does remotes have a way to specify the install in the right order? Duncan Murdoch On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four versions of R: https://www.tidyverse.org/blog/2019/04/r-version-support/. We automatically run checks on all these R versions using GitHub actions. You can use the same config as us by running usethis::use_tidy_github_actions(). If you're already using GitHub, I'm pretty confident that this is the fastest/easiest way to check with older versions of R. Hadley
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 31/01/2021 10:57 a.m., G?bor Cs?rdi wrote:
Do you actually experience any problems, if you don't treat this case specially?
Yes, what was happening was that remotes::install_deps skipped installing rgl from CRAN because the local copy had a later version number. Sorry, I deleted most of the runs that had failures in them, so I can't quote the exact message about this.
AFAIR, in most cases this is not a problem in practice. remotes might install the CRAN version of rgl as the dependency of alphashape3d, but `R CMD check` will install and use the local copy of the rgl package for the check, anyway, so that does not matter much. More precisely, it would only matter if alphashape3d had some install time dependency on rgl, because at install time, it will use the CRAN rgl version. But this is pretty rare I think. If you still want to fix this, you can replace `remotes::install_deps()` with `remotes::install_local()` and then remotes will install the local package as well, not only its dependencies.
I'll try that. Duncan
Gabor On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
I am trying out a modified version of the tidyverse actions, and it does
seem to be going well. Just one question:
rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
dependency on rgl. This means that I need to install in the order
rgl hard dependencies
rgl
rgl soft dependencies
Currently I'm using this code to do that:
# First install rgl with minimal deps then the rest
devtools::install()
remotes::install_deps(dependencies = TRUE)
but devtools seems unnecessarily heavy for this. Does remotes have a
way to specify the install in the right order?
Duncan Murdoch
On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four versions of R: https://www.tidyverse.org/blog/2019/04/r-version-support/. We automatically run checks on all these R versions using GitHub actions. You can use the same config as us by running usethis::use_tidy_github_actions(). If you're already using GitHub, I'm pretty confident that this is the fastest/easiest way to check with older versions of R. Hadley
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 31/01/2021 12:35 p.m., Duncan Murdoch wrote:
On 31/01/2021 10:57 a.m., G?bor Cs?rdi wrote:
Do you actually experience any problems, if you don't treat this case specially?
Yes, what was happening was that remotes::install_deps skipped installing rgl from CRAN because the local copy had a later version number. Sorry, I deleted most of the runs that had failures in them, so I can't quote the exact message about this.
I just re-ran a version of the old one. I'm caching package builds, so now I get alphashape3d anyway, but in case you're interested, the message was: Skipping 1 packages ahead of CRAN: rgl Duncan Murdoch
AFAIR, in most cases this is not a problem in practice. remotes might install the CRAN version of rgl as the dependency of alphashape3d, but `R CMD check` will install and use the local copy of the rgl package for the check, anyway, so that does not matter much. More precisely, it would only matter if alphashape3d had some install time dependency on rgl, because at install time, it will use the CRAN rgl version. But this is pretty rare I think. If you still want to fix this, you can replace `remotes::install_deps()` with `remotes::install_local()` and then remotes will install the local package as well, not only its dependencies.
I'll try that. Duncan
Gabor On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
I am trying out a modified version of the tidyverse actions, and it does
seem to be going well. Just one question:
rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
dependency on rgl. This means that I need to install in the order
rgl hard dependencies
rgl
rgl soft dependencies
Currently I'm using this code to do that:
# First install rgl with minimal deps then the rest
devtools::install()
remotes::install_deps(dependencies = TRUE)
but devtools seems unnecessarily heavy for this. Does remotes have a
way to specify the install in the right order?
Duncan Murdoch
On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote:
Hi, you're probably already aware of it, but 'rgl' depends on 'magrittr' which depends on 'rlang', and the latter requires R (>= 3.3.0).
For the reference, we support R-release, R-devel, and the last four versions of R: https://www.tidyverse.org/blog/2019/04/r-version-support/. We automatically run checks on all these R versions using GitHub actions. You can use the same config as us by running usethis::use_tidy_github_actions(). If you're already using GitHub, I'm pretty confident that this is the fastest/easiest way to check with older versions of R. Hadley
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel