Our rtools patch is apparently not good enough.

To download and install the latest rim version.

Hi

Thanks for the great tool, I think this will make lots of people's lives easier 🎉 ! I have been playing around with getting two installations of the same R version to work. Probably a fairly niche thing so not suggesting you add it as a feature (unless there is demand) but thought I would post my solution in case it was helpful to anyone (and in case there are issues I haven't come across yet). My use case is to have two versions of R 4.2 installed, one with Bioconductor release (for analysis) and one with Bioconductor devel (for development) and to be able to switch between the two as needed.

These are the steps that worked for me on MacOS:

1. Install the desired R version.

rim install release

2. Rename the installed directory

mv /Library/Frameworks/R.framework/Versions/4.2 /Library/Frameworks/R.framework/Versions/4.2-bioc

3. Modify the main R script so that all paths point to the new location

vim /Library/Frameworks/R.framework/Versions/4.2-bioc/Resources/bin/R

Search for all occurrences of the installed R version and modify them to match the new path (eg. change all 4.2 to 4.2-bioc)

4. Modify the base Renviron file to set the default user library path

vim /Library/Frameworks/R.framework/Versions/4.2-bioc/Resources/etc/Renviron

Find where R_LIBS_USER is set and modify it to point to the new installation directory.

R_LIBS_USER=${R_LIBS_USER:-'/Users/user/Library/R/x86_64/4.2-bioc/library'}

(I feel like there should be a way to do this without hard coding a path but haven't really looked into it)

5. Re-install the desired R version.

rim install release

After this I am able to switch between 4.2 and 4.2-bioc with both installations having .libPaths() correctly set to different directories. You probably lose the ability to make updates for new R versions but worth it for me to be able to easily switch between these two environments.

To allow debugging.

For the default version.

If possible.

Something like

rig library list --version <rversion>
rig library default --version <rversion>
rig library default <new-default> --version <rversion>
rig library add --version <rversion>
rig library del --version <rversion>

--version defaults to the current default R version.

Later we'll also have --system and --user for rig library default, to allow setting the default at the user and the system level.

Like on macOS.

rig pin add <package> <package-ref> --version <rversion> --library <library>
rig pin del <package> --version <rversion> --library <library>
rig pin list --version <rversion> --library <library>

--version defaults to the current R version and --library defaults to the current library.

via new rim run command?

$ R --version
R version 4.1.2 (2021-11-01) -- "Bird Hippie"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.

$ rim run 3.5 R --version
R version 3.5.3 (2019-03-11) -- "Great Truth"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.0 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
http://www.gnu.org/licenses/.

The downside of doing this is that it's platform (macOS) specific. However, given the default architecture will be x86_64 even on arm64 Macs (which makes sense, given it's in line with R distributions), it'd be nice to have the -a/--arch option be more visible in the docs/help examples.

I'd been doing, e.g. rig add 4.2-arm64, not realizing you could use devel and release with -a arm64 until I saw you do so in your demo. Basically: I think it's worth highlighting because it's handy!

Hey,

Thanks a lot for rim! That was much needed, awesome.

On mac, I think rim list shouldn't print .DS_Store?

colin$ rim list
.DS_Store
3.4
3.6
4.1
4.2

From #7.

It would be nice to be able to start specific versions of R, instead of switching from one to the other with default.

For example, instead of

rim default 4.2.0
R
# [... try the new version...]
q()
rim default 4.1.2
R
# [... get back to where I was at...]

It would be cool to be able to do:

rim start 4.1.2
# [... try the new version...]
q()
# [... still have the default version...]

For setup-r:

• Linux support (#7)
• Remove -fopenmp flag on macOS (#13)
• Set up RSPM (#15)
• Add Rscript to the PATH (#20)
• Update Rtools40 (#14)
• Set default CRAN mirror to cloud, in addition to RSPM, potentially (#11)
• Install gfortran on macOS (#21)
• Install system utilities on macOS (#22)
• Support Rtools42 on Windows (#23)

EDIT: we don't necessarily need these now, they can be implemented later:

For setup-pandoc:

• Install pandoc (#16)

For setup-tinytex:

• Install tinytex (#17)

And maybe another subcommand to allow core files. E.g.

rim system allow-debuggers
rim system allow-core-dumps

allow-core-dumps should set the write access to the /cores directory, in addition to setting the entitlement.

Since we are using the apple compilers.

A nice tool I never imaged!

I have a suggestion here.

C:\Users\Administrator>rim list
4.1.2
4.1.3

When 4.1.3 set as default, adding a mark may be more readable, so no need to call rim default.

C:\Users\Administrator>rim list
4.1.2
4.1.3 (default)

Also, I just tried the rim, I found after I install the 4.1.3, the RStudio use 4.1.3 already, however, rim did not point 4.1.3 or 4.1.2 as default. I don't know if they should be consistent.

Potentially all versions that are needed.

I'm running elementary OS 6.1 which is built on Ubuntu 20.04.3 LTS. Runing rim add results in this error:

thread 'main' panicked at 'Unsupported distro: elementary 6.1, see rim list-supported', src/linux.rs:525:5

I don't know if there's a safe programmatic way to check if any particular distro is based on Ubuntu so the solution could be to allow the user to bypass the auto-discovery and specify the version to install (under their own risk, naturally).

If it helps, my /etc/os-release looks like this:

NAME="elementary OS"
VERSION="6.1 Jólnir"
ID=elementary
ID_LIKE=ubuntu
PRETTY_NAME="elementary OS 6.1 Jólnir"
LOGO=distributor-logo
VERSION_ID="6.1"
HOME_URL="https://elementary.io/"
DOCUMENTATION_URL="https://elementary.io/docs/learning-the-basics"
SUPPORT_URL="https://elementary.io/support"
BUG_REPORT_URL="https://github.com/elementary/triage/issues/new"
PRIVACY_POLICY_URL="https://elementary.io/privacy-policy"
VERSION_CODENAME=jolnir
UBUNTU_CODENAME=focal

Apparently, rim.exe is not self-contained on Windows, and it needs vcruntime140.dll.

Until this is fixed in the next rim version (soon), you can install the MCVC++ runtime from here:
https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2015-2017-2019-and-2022
You'll need the X64 version, i.e. https://aka.ms/vs/17/release/vc_redist.x64.exe

• qpdf
• pkgconfig
• checkbashisms

From brew or some other source?

Apparently. On Big Sur I get

Updating entitlements of /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/bin/exec/R
thread 'main' panicked at 'Cannot query entitlements:
   codesign: unrecognized option `--xml'
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
       codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
       codesign -d [options] path ... # display contents
       codesign -h pid ... # display hosting paths
', src/macos.rs:322:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I had a few questions about the quick links that got installed when I did rim add release. I will refer back to the results of rim list, so here is that for now:

$ rim list
.DS_Store
3.3
3.6
4.0
4.1
4.2

1. (Ah, this is #36) What is up with the .DS_Store one? It shows up in rim list and I get:

Adding /usr/local/bin/R-.DS_Store -> /Library/Frameworks/R.framework/Versions/.DS_Store/Resources/bin/R

2. Why does R-4.0 get added and then removed?

Adding /usr/local/bin/R-4.0 -> /Library/Frameworks/R.framework/Versions/4.0/Resources/bin/R
...
Cleaning up /Library/Frameworks/R.framework/Versions/4.0/Resources/bin/R

3. Why do all quick links link to R 4.1.3? Look at the opened version of R here.

With rim add <filename> as usual.

i.e. it created /Users/davis/Library/R/x86_64/4.1/library when I ran rim add release.

Is it just good practice to keep your CRAN R package library separate from the base R packages? I've never used a separate library before.

I guess R knew to find it there because of this?

> Sys.getenv("R_LIBS_USER")
[1] "~/Library/R/x86_64/4.1/library"

> .libPaths()
[1] "/Users/davis/Library/R/x86_64/4.1/library"                     
[2] "/Library/Frameworks/R.framework/Versions/4.1/Resources/library"

Using https://github.com/rstudio/r-builds

$ rim system
thread 'main' panicked at 'Usage: rim system [SUBCOMMAND], see help', src/main.rs:56:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I was expecting it to actually print out the help like what happens when I just type in rim

Hi,

Today I tried to install rim in a HPC without root permission. I found it require sudo to install R release. Could rim work for such case?

Best,

Shixiang

This is hard because the installer simply overwrites the symbolic link. One possible solution is creating a volume, installing there, removing the link, and then moving the files to the / volume.

Another possible way is to extract the .pkg file with pkgutil --extract, removing the symlink, and then pack it back up with pkgutil --flatten. Well, except that the contents is in a big Payload file after extracting, which is a cpio file, so we would need to remove it from that. Also, if there is some integrity check on the .pkg then this will not work.

A technically worse but probably good enough approach is to watch the disk while the installer is running and as soon as the /Library/Frameworks/R.framework/Versions/Current link is (re)created, we set it back to the previous default.

Using clap_mangen it is already possible to generate it automatically, but it still has some glitches, so we'll need to wait a bit.

In practice it is tied to the R version it came with, so this will be possibly hard.

Maybe the whole rtools stuff should be a separate command? Or keep it in rim add, and have rim list --rtools as well?

Or packages from brew. Maybe after we have better sysreqs.

Ideally before downloading. Otherwise, I need to wait for the download before I see the error message.

• Make sure README has the correct command list.
• Make sure version number is updated everywhere:
  • Cargo.toml
  • Cargo.lock (run cargo build)
  • src/args.rs
  • rim.iss
  • NEWS file
  • README.Rmd
• Make sure CI is OK
• If needed, commit to to have a CI build with the right version number.
• Build README:

  Rscript -e 'rmarkdown::render("README.Rmd")'
  

• Update NEWS header to remove (not released yet)
• Build signed and notarized macOS packages locally:

  export AC_PASSWORD=...
  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  make clean
  make macos
  

• Download the artifacts for the new version for Windows & Linux (x2)
• Create tag for the current version, push to GH.
• Create release on GH, add the installers.
• Test installers.
• git commit with the NEWS and README updates, update tag, push to GH,
  --tags as well.
• Update homebrew repo.
• Update choco package.

Tested on Linux/Ubuntu 22.04 with rig 0.3.1 pre-release.

❯ rig --version
RIG -- The R Installation Manager 0.3.1
❯ pwd
/opt/R
❯ ls
4.1.3  4.2.0  current  etc
# current is a symlink to 4.2.0, as expected
❯ rig ls
4.1.3
4.2.0 (default)
etc

I personally use /opt/R/etc for global Rprofile.site/Renviron.site and symlink those into respective R version directories to set some options.
This workflow is not ideal, I know (haven't found a neater solution, but I wrote my helper scripts and, well, "it works").

In general I think it seems reasonable to expect rig ls to e.g. only show directories starting with a digit, e.g. matching $\d or \d\.\d\.\d etc.

In a previous version I also noticed rim ls listing a .DS_Store file on macOS, but this appears to not be an issue anymore.

We don't really need to leave this to the user.