Re: [R-pkg-devel] Testing on old R versions

2021-02-01 Thread Gábor Csárdi
On Sun, Jan 31, 2021 at 6:52 PM Duncan Murdoch  wrote:
>
> 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

Right. This is probably because in some iteration you installed the
local (dev) rgl into the library that is cached.
It should still be harmless, because `R CMD check` uses the (new)
local package for the check. The old cached version is only used for
installing alphashape3d and other suggested packages that import or
depend on rgl.

In any case, `remotes::install_local()` seems to be the safest way to
go about this currently.

Gabor


> 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
> >>  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
>   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@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] Testing on old R versions

2021-01-31 Thread Duncan Murdoch

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
 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
 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@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] Testing on old R versions

2021-01-31 Thread Duncan Murdoch

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
 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
 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@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] Testing on old R versions

2021-01-31 Thread Gábor Csárdi
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
 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
> >  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@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] Testing on old R versions

2021-01-31 Thread Hadley Wickham
On Sun, Jan 31, 2021 at 4:32 AM Duncan Murdoch  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

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Testing on old R versions

2021-01-31 Thread Duncan Murdoch
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
 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Testing on old R versions

2021-01-29 Thread Duncan Murdoch
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  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 | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



Re: [R-pkg-devel] Testing on old R versions

2021-01-28 Thread Henrik Bengtsson
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  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 | 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] Testing on old R versions

2021-01-28 Thread Dirk Eddelbuettel


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 | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Testing on old R versions

2021-01-28 Thread Duncan Murdoch

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



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Testing on old R versions

2021-01-28 Thread Nathan Watson-Haigh
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  on behalf of 
Duncan Murdoch 
Sent: Friday, January 29, 2021 1:35:40 AM
To: r-package-devel@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[[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] Testing on old R versions

2021-01-28 Thread Dirk Eddelbuettel


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 | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Testing on old R versions

2021-01-28 Thread Neal Richardson
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 
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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[R-pkg-devel] Testing on old R versions

2021-01-28 Thread Duncan Murdoch
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel