This excellent writeup on the NAU Locale inspired me to ask if there are alternative methods used elsewhere that aren’t covered in this note.
I think this is covered in that note, but for installing R packages with complex dependencies, we recommend creating a Conda environment that includes libraries for each R script they might use in a particular workflow. Here is our Conda documentation.
Some folks have found they needed to specify the version number of nearly every single package to get things correct - in particular, this happens if they are say, developing code on a Mac over a year or two and then try to port to HPC. By the time they finish their script, they have a very peculiar set of dependencies needed to run their scripts without error. With Conda, you can specify the version of each dependency.
Some R packages are not available through Conda. In that case, you create the base Conda environment, activate it, and then do “install.packages” as usual. Those packages will be installed and available through that Conda environment.
One thing that differs from the instructions in the link that you mentioned…you should not do both ‘module load R’ and ‘conda activate’. When you create a Conda environment with the R packages, it will contain it’s own R (version and environment variables!), which going to be different than the one in your module. (Here is our R documentation.) In general, use modules, use Spack, or use Conda…but DON’T CROSS THE STREAMS!!! 
Yeah, for a multi-user environment, I would discourage the use of Conda.
The latest R 4.1.3 builds pretty easily, even linking with MKL.
Perhaps Spack is the way to go for maintainability.
For installing packages, our site recommends each user install packages themselves. That way, the issue of having conflicts between R packages due to different requirements from different users is reduced (but not eliminated).
To clarify, I don’t use Conda to do the systemwide R install. I install R in the usual way (configure/make, with mkl).
I recommend that if someone’s scripts use R libraries with a bunch of complicated external library dependencies, then they should create their own Conda environment, installed via yaml file containing every library used in their scripts. That’s the best way (or at least easiest way) to get the right version combo of R, R libraries, and dependencies.
Before finding Conda, we would install the systemwide R with commonly used packages, and ask users to install their own libraries as usual with ‘install.packages’. I can’t even count how many tickets were opened asking us why their rgdal installation didn’t work. And even more saying they needed a different version of gcc.
Mostly to reinforce your point on not crossing the streams, in case it helps others:
I have more experience with python. And I’ve seen that generally mixing conda+pip installs can cause breakage. But running conda then running pip, and NOT editing the environment with conda again is safe. Because conda can’t keep track of the changes made externally.
It should be the same with R too. Running conda first is helpful to install the packages, that’d otherwise require system-wide dependencies, into a conda env. Then you can use install.packages in R to do the rest.
Absolutely right that someone shouldn’t do an lmod load for both R and conda. One or the other 
. To briefly summarize the options users have for R:
- load R and run install.packages
– By default this will put your R packages in /home
– if need a different version of R or run into system dependency issues then move to 2 - load conda, and create an R environment
– install any conda packages you want here, if you need some niche R packages move to 3 - using the same conda env you created in number 2, run install.packages in R for the rest
Number 3 here definitely isn’t a hard rule, getting the R packages from conda can work too. But CRAN may have R packages not available in conda and it may have more up-to-date package versions. As a lesser caveat, if you find yourself creating environments often, conda can be slow to resolve complex environments.
Side note: R will prompt users about creating a personal library if it’s their first time installing packages. We often get questions about this from new users, simply say yes and it’ll create that ~/R/ directory.