Daily Shaarli

All links of one day in a single page.

May 4, 2025

Don't tag Ansible roles in dependencies

I just realized why my plays keep re-running roles when running a certain role.
It is because I have dutifully replicated the same parameters used in the play for each role in the dependencies list, which includes the tags parameter.

So when I call the play with --tags R, the R role (which is tagged eponymously) triggers, but also any role in the play which lists R in its dependencies, because I tagged the dependencies!

The solution is obvious and I am embarrassed it has taking me so long to realize: do not tag roles in the dependencies list!

A rudimentary direnv example with per-project R versions

Considered because I was trying to answer the question:

Can we use a different R version per directory/project?

With my R role it has been easy to maintain multiple different R versions on a server. But I have not really been able to pick-and-choose which R version to use with any particular project since there was only one version symlinked globally (/usr/local/bin/R -> ...).

Could we not set a different version locally, in a particular R project?

asdf

After reading about it a little, I get the feeling it would be more cumbersome than direnv.
I am not sure I understood correctly, but sounds like the R plugin actually wants to manage the
entire R installation (essentially what rig does).

direnv

I cannot find anyone talking about direnv with R on the web. Weird.

[So what I want] is a "shim" binary that dispatch to the desired binary
https://mise.jdx.dev/dev-tools/shims.html

The .envrc file is treated like a shell script, where you can also list arbitrary
shell commands that you want to be executed when you enter a project directory.
http://rednafi.com/misc/direnv/#why-envrc-file-and-not-just-a-plain-env-file

My direnv example

Machine in question is Ubuntu 22.04 x64.

$ apt install direnv
$ printf 'if hash direnv >/dev/null 2>&1; then\n   eval \"$(direnv hook bash)\"\nfi' >> ~/.bashrc

In the R project directory, I created a subdirectory bin (for convenience) and created a symlink to the R binary I wanted, naming it R. Also added this subdirectory to .gitignore (and .Rbuildignore if it's an R package).

In the package directory I created .envrc containing simply:

PATH_add bin

And enabled with direnv allow the first time I cd into the directory.
Now the R command defined in bin successfully overrides the system-wide command:

$ ls -l `which R`
lrwxrwxrwx 1 taha taha 18 maj  3 21:47 /media/bay/R/periodicdata/bin/R -> /opt/R/4.5.0/bin/R

Note that this works in the terminal. I am pretty sure we will need to do more to have IDEs such as RStudio Server or Codium Server take heed on a per-directory basis. Will investigate further as time permits.

Support for direnv in RStudio Server, Codium, et al.

code-server just works. Well, except for the "Attach R" button, which still only uses the system-wide R binary.

VSCodium would have worked, except I installed and configured direnv on the server, and VSCodium runs on my desktop. Expected, and easily fixed by installing and configuring direnv on the desktop too, if desired.

VSCodium with the Remote SSH plugin. It's complicated. Seems the languageserver component (which the VSCodium R plugin uses) sees the system-wide R binary, despite definitely picking up on the directory-specific renv.
And the VSCodium "Attach R" button (in the statusbar) works but attaches the system-wide R binary. But running R in the built-in terminal respects our direnv config.

RStudio Server fares similarly, in that the built-in terminal behaves like any terminal and respects our direnv config, but the built-in "R Console" does not, and neither do the other built-in buttons etc. But it feels worse because a lot of stuff will automatically run in the Console and thus use the wrong R version. Unfortunately Posit still to this day lock their "multiple versions of R" functionality behind a "Pro" license.

I guess one (really ugly) work-around would be to run multiple RStudio Server instances, each with a hard-coded R version: export RSTUDIO_WHICH_R=.... For R package development it's primarily R-release and R-devel that matters, so it's not unworkable. And I have been known to run multiple instances anyway (one per LXC container).

More links and notes

R versions

At present 2025-05-03:

  • R-devel is NA
  • R-patched is NA
  • R-release is 4.5.0
  • R-oldrel is 4.4.3

This is best determined using the rversions:: package!