如何在旧的不兼容版本的R上安装新的R包

Question

I am forced to use R 3.2.2 due to IT requirements at my company. I need to use a few packages that technically require R > 3.2.2 (chiefly prophet version 2 or greater). I know that sometimes it is possible to "trick" the package into running in the older, incompatible version of R but I am unsure how to do this.

I downloaded the package using a newer version of R, then adjusted the description file as suggested by Patrick here ( How to install an R package to R-3.3.0 from GitHub, which is built on R-3.4.0? ), and moved the package file into the R 3.2.2 library path but it didn't work. I get the error "Error: This is R 3.2.2, package 'prophet' needs >= 3.2.3."

Does anyone have ideas/suggestions? Thank you!

Answer 1

Up front: @prosoitos' comment about using older versions of packages is likely your best bet, if you can find them. I believe that MRAN claims to have daily versions of all packages going back quite a ways, along with the checkpoint package for freezing the state of packages for your project. In fact, try using that package, it might make several of the below "tricks" (please don't use them casually) unnecessary.

---

It is true that some packages may "falsely require R versions", instead conveniently choosing the version of R the developer is using and/or an arbitrary version they copied from another package. However:

1. There is no way for you to know if it is a true requirement without knowing the internals of the package code.

   If the developer is conscientiously using appropriately-defined R version requirements, you can go through the commit history of the package (assuming github, gitlab, or some other accessible version control) and find when the R version changed in DESCRIPTION , and look at the previous commit(s) to see what change suggested the version increase. If you're lucky, the commit messages themselves will say something like "add argument xyz=, requiring newer R" , but that's not guaranteed or even likely, I suspect.

2. Lacking that, there might be one function (legacy or new) that requires the newer version of R, but nothing else was changed. This seems plausible to me, and again might require some sleuthing to confirm.

3. Even if you find this, it is likely that it depends on other packages that have similarly-defined version requirements. So even if you figure things out for one package, it may cascade into several or dozens of packages. (Hint: perhaps checkpoint is looking better, as it helps with this.)

If you somehow determine that either (a) you know that the R-version requirement is wrong, or (b) you know what it requires and you're willing to live without those arguments or functions, then:

1. Clone or download the source;
2. Edit DESCRIPTION and change the R version, and I suggest you change the package version number as well so that you know which version you are using; and you should note the version requirements for other packages, too, as it may hint at API changes, etc; and
3. Build/install the local version.

But ... there might be nuances to the code (and/or example code in documentation) that will not work in the older version. AND, what works for one package will not necessarily work for another.

This is a true case of caveat emptor. The risk of code breaking is high. The likelihood of having to do this manual process for several packages is high. The likelihood that it all works the first time is low.

(Of course, you could always reach out to the developer/maintainer to ask.)

Answer 2

It is not the exact answer to your question. But did you hear about conda package manager (which is universal to programming languages and many other system-relevant programs)?

You could resolve your headache - without admin rights - by locally installing higher versions of R into a virtual conda environment - and have it and run it in a virtual environment.

To learn to use conda use Corey Schafer's tutorials are very good - and teaches you conda within merely 12 min ... . Anaconda is just a variant, but I use miniconda - the produre and the command is the same.

# install miniconda on linux 64 bit on python 3.7 background
wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh

# linux 32 bit python 3.7
wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86.sh
bash Miniconda3-latest-Linux-x86.sh

# windows 64 bit python 3.7
wget https://repo.continuum.io/miniconda/Miniconda3-latest-Windows-x86_64.exe
# and run it 

# windows 32 bit python 3.7
wget https://repo.continuum.io/miniconda/Miniconda3-latest-Windows-x86.exe
# and run it

# other combinations and conditions and operating systems and python 2.7
# https://conda.io/miniconda.html

# after installation, in terminal, conda is available from 
# wherever you are.
# create conda environment for R-3.5.1 the newest
conda create --name R351
# enter the virtual environment
source activate R351
# install R-3.5.1
conda install -c r r-base
# start R
R
# quit R and quit the environment
source deactivate

I searched long for version problems like this. And this was the cleanest solution ...

But actually also without conda, you can just locally install higher R versions (for this you don't need sudo rights) and run the "/path/to/your/local/R-3.5.1/bin/R" - eg - I do it indeed. Binaries or sources you get from here . However, in this case you often have to install packages as admin.

Using the .libPath() function, you can get full control over which libraries - which are located in folders - should be accessed/used or not. See here .