add note about r-dependent-packages feature
#115
Conversation
|
|
||
| - `r-dependent-packages` supports package installation from a `DESCRIPTION` file via | ||
| ([`pak::local_install_deps()`](https://pak.r-lib.org/reference/local_install_deps.html)) after container startup. | ||
| - `renv-cache` supports package installation via [the `renv` R package](https://rstudio.github.io/renv/) after container startup. |
There was a problem hiding this comment.
Out of curiousity: Why do use pak when you could use r2u? Some of us (eg Grant) had good luck with r2u in devcontainers; he promoted that at work too AFAIK.
There was a problem hiding this comment.
My understanding is that r2u can only be used in limited situations:
- Does not support arbitrary CRAN URLs
- Only amd64 Ubuntu is supported
I expect that a version using r2u could be created by using something like remotes::install_deps() instead of pak::local_install_deps(), but I don't know if there is demand for it.
There was a problem hiding this comment.
For example, this is an example I am actually using, but this set an additional repository and installed polars from R-universe, so perhaps bspm can't handle this?
"ghcr.io/rocker-org/devcontainer-features/r-dependent-packages": {
"when": "updateContent",
"additionalRepositories": "polars = 'https://rpolars.r-universe.dev'",
"dependencyTypes": "all,Config/Needs/dev,Config/Needs/website"
},There was a problem hiding this comment.
That is incorrect. Just give it a try.
We (at work) use install deps from remote all the time with r2u in CI and other settings. I use it all the time to debug a repo. It gets all it can via apt, what it cannot ("Additional_repositories") it still installs the usual way. I personally use it via littler wrappers installDeps.r and installDeps2.r (a bit like the install.r and install2.r story: eventually I wanted more options). In short, because Inaki did the Right Thing (TM) tracing install.packages is still works here.
I also use things like polars from r-universe and have a wrapper installRub.r for that. I am unsure what remotes does here so I usually just combine the two with two calls: installRub.r for what I want from r-universe, standard remotes::install-deps() in lieu of install.packages. Happy to demo.
(Nothing wrong with pak. But for Ubuntu as we often use for containers etc I feel r2u (fairly clearly) dominates. Speed is one thing, the better logic from integrating with the system package manager is another. But tastes vary so 🤷♂️ )
(Only amd64 is very much true. Given that apt repos can mix 'Architecture: all' (ie nothing binary) and 'Archtitecture: any' (binaries) and that binaries are 'merely' 23% it should be possible to add, say, arm64 for those 23%. But I don't have a machine to do it on ... If only a certain large company behind, say, their Graviton chips could be persuaded it helps them too....)
There was a problem hiding this comment.
Maybe worth paging @grantmcdermott simply because he is such a fan and user of both polars (and duckdb) and r2u and devcontainers.
There was a problem hiding this comment.
Okay, thanks.
If that's the case, it might be worth adding an option to use remotes::install_deps() as the function for installation.
There was a problem hiding this comment.
I actually wrote (based on noodling with Grant) a post on this for r2u and devcontainers with r-universe:
https://dirk.eddelbuettel.com/blog/2023/08/15/#041_r2u_and_codespaces The container will now have expired but the demo was explicitly about combining with non-CRAN assets as our friends at CZI were doing just that.
No description provided.