Tutorial:Installing an updated R version (>=4.0) using conda
Entering edit mode
12 weeks ago
Nitin Narwade ▴ 680

I was using Seurat v3.2 and I did most of my single-cell analysis using this version. But today I started working on another dataset and there I encountered this error [[<- defined for objects of type "S4" only for subclasses of environment. I googled about it and I got to know that this is something to do with the Seurat version. This GitHub issue suggesting that if we update the Seurat version, it should fix this problem.

Well, with this lead I started googling about how to update the Seurat and eventually R version using conda. Here you may have a question, why specifically using conda? The reason is, I am a student and working on the university server, thus I do not have ample privilege to install a tool/software directly using system command.

Back to the story, I googled about how to update the R version using conda and I ended up with the possible solutions (also reported on StackOverflow). Somewhere it was mentioned that if we uninstall conda r-base using the conda uninstall r-base command and re-install the same, it should fix the problem. Well, I would say this could be a nice trick to resolve such issues. I mean simply, uninstall conda r-base and install an updated version (R>=4.0) in one environment and R3.2 in another. But unfortunately, in my case, it was not an optimal choice. Because I am working on different projects and to deal with them I have already configured other R packages. So, you see? it's not only about Seurat, and I can not simply mess up with my R environment, just to update the Seurat version, right?

Therefore, again, I started communicating with google about updating R and tried the solutions described above. While trying other solutions I realized that it is something to do with conda channels that I am using. Because on here, they have clearly mentioned the R version but when I was trying to install R4.0 it was not going through the conda-forge channel, instead, it was redirected to a different channel. In fact, the same channel (checked with conda info command) that I had set long back to install R3.2.

With the help of google, finally, I found the solution.

Here are the commands that I had used to resolve this issue:

  1. An updated R version (>=4.0) is available through the conda-forge channel, so first add the channel.

    conda config --add channels conda-forge

  2. We are going to install R through conda-forge and not through the default channel, so we need to set its priority over the default channel.

    conda config --set channel_priority strict

    NOTE: You can undo this change by setting strict priority to the default channel as described here.

  3. Check whether an updated R version is added in the conda search space or not.

    conda search r-base

  4. Now, it is always a good practice (recommoned here) to create a new conda environment, which will help to debug the package-specific and compatibility issues without disrupting the base environment.

    conda create -n seurat4 python=3.6

  5. Let's activate the newly create conda environment.

    conda activate seurat4

  6. And finally install the R package.

    conda install -c conda-forge r-base

I hope this will help someone in the future and save their time.

Cheers :)

R software error Tutorial • 1.6k views
Entering edit mode

Good tutorial. As a shortcut to create an environment with seurat v4 you can do conda create -n seurat -c conda-forge -c bioconda r-seurat=4*. The environment can be activated with conda activate seurat, and updated with conda update -c conda-forge -c bioconda -n seurat --all.

Entering edit mode
12 weeks ago

Loosely related, install mamba in the base environment and use mamba install instead of conda install from then on. E.g.

conda install -c conda-forge mamba
conda create ...
conda activate ... 
mamba install ... r-seurat

mamba is much faster and better behaved than conda (for example see here). It should be pretty stable by now (snakemake, whose creator is behind bioconda, should be installed via mamba).

Entering edit mode
4 weeks ago
Biodeer ▴ 10

I just did it yesterday. For your convenience, get the packages list from the old version R and install them in new version. Here is code

mypackages <- installed.packages()[,c('Package','Version','LibPath')] %>% as.data.frame()
write.csv(mypackages, "./mypackages.csv")

pks <- read.csv("mypackages.csv")
list.of.packages <- pks$X

#checking missing packages from list
new.packages <- list.of.packages[!(list.of.packages %in% installed.packages()[,"Package"])]
packToInst <- setdiff(list.of.packages, installed.packages())
lapply(packToInst, function(x){
BiocManager::install(x,ask = F,update = F)
lapply(intersect(packagesReq, installed.packages()),function(x){
suppressPackageStartupMessages(library(x,character.only = T))
Entering edit mode

It would be much easier to use a dedicated package for handling package versions. I recommend https://rstudio.github.io/renv/articles/renv.html

In a nutshell, you make a snapshot of your active RProject which creates a so called renv.lock file which is a JSON file with all package versions and its dependencies. Basically, the tool goes through all R scripts in that project and scans for require() and library() commands, then collects the packages and its dependencies. The problem with your solution is that it does not track down the dependencies so it can well be that results will not be reproducible even on the same machine if in a new installation dependencies get updated. It also will not download and install packages from Github or other non CRAN/Bioc repositories (I guess). Renv takes care of properly tracking all that.

Renv is also project-specific so you can have multiple projects on the same machine, all with their own local package library rather than having everything installed in the system library. That means different projects can have different package versions on the same machine, without that you have to fiddle with manually setting and changing the package library path. For the end user it really comes down to just calling a few renv command. Restoring the environment from the lock file would only require to have that renv.lock in the project directory and then running renv::restore() (assuming that external dependencies such as e.g. zlib are available on the machine). This is much better than custom solutions, and at least takes care of reproducibility on the same machine. For full reprodicibility you would need a container-based solution such as Docker or Singularity.

Here is an example of the renv JSON, which includes the R version, package repositories and versions:

Entering edit mode

Hi, ATpoint. Thank you very much. I will give it try next time.


Login before adding your answer.

Traffic: 1484 users visited in the last hour
Help About
Access RSS

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6