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!
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.
2023 Update: MRAN is retired. Posit (formerly the RStudio company) has its Posit Package Manager, which provides (afaict) all of the benefits/capabilities of MRAN; they even have a guide to migrate from MRAN (though really it doesn't need much, the migration is rather straight-forward).
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:
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.
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.
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:
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; andBut ... 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.)