27

I am trying to install the "tm" package but then I get an error saying that "tm" is not available for my R version

package ‘tm’ is not available (for R version 3.0.2)

But then I saw that someone suggested I download the archived version from

http://cran.r-project.org/src/contrib/Archive/tm/?C=M;O=A

and then try installing from source.

My question is how do I determine which file there in the list is compatible with my R version?

London guy
  • 27,522
  • 44
  • 121
  • 179
  • 2
    Every package has a DESCRIPTION file that should list it's requirements. I suggest looking at a version in the Archives from early 2014 or mid 2013. – IRTFM Feb 27 '15 at 14:08
  • Related: https://stackoverflow.com/questions/16091304/efficiently-getting-older-versions-of-r-packages – Scarabee Aug 02 '18 at 14:43

5 Answers5

13

I developed an answer related to the approach here, but which uses only base R (you don't need XML or devtools or anything). It also potentially handles some contingencies that may not be addressed by the solution I linked to from the other question. Since it was around 100 lines of code, rather than just post a huge function here, I rolled it into a package oldr you can get from GitHub here:

oldr package GitHub repo

The package has just one exported function, install.compatible.packages(). I have tested it on Ubuntu 18.04. I installed R 3.1.0 and installed tm (and its dependencies). The current version of tm requires R 3.2.0, so wouldn't be available via install.packages(), but my function allows its installation:

> oldr::install.compatible.packages("NLP")
Installing package into ‘/home/duckmayr/R/x86_64-unknown-linux-gnu-library/3.1’
(as ‘lib’ is unspecified)
* installing *source* package ‘NLP’ ...
** package ‘NLP’ successfully unpacked and MD5 sums checked
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (NLP)
> oldr::install.compatible.packages("slam")
Installing package into ‘/home/duckmayr/R/x86_64-unknown-linux-gnu-library/3.1’
(as ‘lib’ is unspecified)
* installing *source* package ‘slam’ ...
** package ‘slam’ successfully unpacked and MD5 sums checked
** libs
gcc -I/opt/R/3.1.0/lib/R/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O2  -c apply.c -o apply.o
gcc -I/opt/R/3.1.0/lib/R/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O2  -c grouped.c -o grouped.o
gcc -I/opt/R/3.1.0/lib/R/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O2  -c sparse.c -o sparse.o
gcc -I/opt/R/3.1.0/lib/R/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O2  -c util.c -o util.o
gcc -shared -L/usr/local/lib -o slam.so apply.o grouped.o sparse.o util.o -L/opt/R/3.1.0/lib/R/lib -lRblas -lgfortran -lm -lquadmath -L/opt/R/3.1.0/lib/R/lib -lR
installing to /home/duckmayr/R/x86_64-unknown-linux-gnu-library/3.1/slam/libs
** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (slam)
> oldr::install.compatible.packages("tm")
Installing package into ‘/home/duckmayr/R/x86_64-unknown-linux-gnu-library/3.1’
(as ‘lib’ is unspecified)
* installing *source* package ‘tm’ ...
** package ‘tm’ successfully unpacked and MD5 sums checked
** libs
gcc -I/opt/R/3.1.0/lib/R/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O2  -c copy.c -o copy.o
gcc -shared -L/usr/local/lib -o tm.so copy.o -L/opt/R/3.1.0/lib/R/lib -lR
installing to /home/duckmayr/R/x86_64-unknown-linux-gnu-library/3.1/tm/libs
** R
** data
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (tm)

Update: Testing on Windows

I now have also had the chance to test on Windows (8.1), and everything worked smoothly for installing tm to an old version of R (v. 3.1.0):

> oldr::install.compatible.packages("NLP")
Installing package into ‘C:/Users/User/Documents/R/win-library/3.1’
(as ‘lib’ is unspecified)
trying URL 'http://mirror.las.iastate.edu/CRAN/bin/windows/contrib/3.1/NLP_0.1-9.zip'
Content type 'application/zip' length 278699 bytes (272 Kb)
opened URL
downloaded 272 Kb

package ‘NLP’ successfully unpacked and MD5 sums checked

The downloaded binary packages are in
        C:\Users\User\AppData\Local\Temp\RtmpojDNlF\downloaded_packages
> oldr::install.compatible.packages("slam")
Installing package into ‘C:/Users/User/Documents/R/win-library/3.1’
(as ‘lib’ is unspecified)
trying URL 'http://mirror.las.iastate.edu/CRAN/bin/windows/contrib/3.1/slam_0.1-32.zip'
Content type 'application/zip' length 111528 bytes (108 Kb)
opened URL
downloaded 108 Kb

package ‘slam’ successfully unpacked and MD5 sums checked

The downloaded binary packages are in
        C:\Users\User\AppData\Local\Temp\RtmpojDNlF\downloaded_packages
> oldr::install.compatible.packages("tm")
Installing package into ‘C:/Users/User/Documents/R/win-library/3.1’
(as ‘lib’ is unspecified)
trying URL 'http://mirror.las.iastate.edu/CRAN/bin/windows/contrib/3.1/tm_0.6-2.zip'
Content type 'application/zip' length 710798 bytes (694 Kb)
opened URL
downloaded 694 Kb

package ‘tm’ successfully unpacked and MD5 sums checked

The downloaded binary packages are in
        C:\Users\User\AppData\Local\Temp\RtmpojDNlF\downloaded_packages

Update: Additional Parameters

Now users can specify which version of R to attempt installation for (R_version parameter), and which directory to install packages to (lib parameter), which could be useful for testing or other purposes.

duckmayr
  • 16,303
  • 3
  • 35
  • 53
  • Thank you for your work! I will test it ASAP. It would be great to have a `R_version` parameter that would be current version by default but allow installations compatible with earlier versions (for testing or reproducibility). – moodymudskipper Aug 03 '18 at 22:46
  • @Moody_Mudskipper I've just added a couple of cross-platform and backwards compatibility fixes, so be sure to pull the new changes. Hopefully this will be helpful for people; I know I've run into this issue more than once myself on servers where I can't upgrade the R version. – duckmayr Aug 03 '18 at 23:21
  • @Moody_Mudskipper That's a great idea. I'll try to add that feature tomorrow. – duckmayr Aug 03 '18 at 23:22
  • @Moody_Mudskipper I now have this feature implemented. Users can specify which versions to attempt installation for, as well as where to install packages to (allowing for installing for multiple versions to different library directories). – duckmayr Aug 06 '18 at 00:56
  • @Moody_Mudskipper No prob! After testing on Mac and with R back to 2.15.0, I figure I'll go ahead and put this up on CRAN; hopefully it might save someone a little bit of trouble. – duckmayr Aug 09 '18 at 10:32
  • I've done some work on my side as I wanted to try a solution based on crandb, I'll post my take on this here though it has some flaws, it's interesting for dependencies, maybe you'll be interested. Good idea to put in on CRAN, if you do one neat feature that I think fits well into your scope would be to integrate a function (or argument) that allows to attempt the installation of a package even if installation of R is too old according to description file, see comment on @Scarabee's question. – moodymudskipper Aug 09 '18 at 10:38
  • 1
    I can definitely try that out, and I'll be interested to see your crandb based solution. – duckmayr Aug 09 '18 at 10:42
11

You can use the METACRAN mirror:

Go to the blame page of the DESCRIPTION file of the package you're interested in.

E.g. for tm: https://github.com/cran/tm/blame/master/DESCRIPTION

enter image description here

Find the Depends line and click as many times as needed on the View blame prior to this change icon, until an old enough R version is displayed.

If you want to automate that, it may be better to use crandb (also from METACRAN).

Side note: sometimes package authors list R (≥ x.y.z) as a dependency just to be safe because they use version x.y.z and didn't do any tests with previous versions.

Scarabee
  • 5,437
  • 5
  • 29
  • 55
  • 2
    Thanks, this is helpful. About your sidenote, it's something I've noticed, is there a way to take a chance at installing the package without downloading / unzipping / editing / rebuilding the package ? – moodymudskipper Aug 02 '18 at 16:59
  • @Moody_Mudskipper Not that I know of. – Scarabee Aug 02 '18 at 17:21
2

You can download the archived package and then untar and un-gzip it. The DESCRIPTION file lists the version of R that it needs. In your case the file tm_0.5-10.tar.gz (that is, the most recent archive version, but not the current version) has this line:

Depends: R (>= 3.0.0)

Version 0.6 of the tm package updated its dependency to R greater than or equal to 3.1.0.

Lincoln Mullen
  • 6,257
  • 4
  • 27
  • 30
2

Another option would be to upgrade your version of R so it is compatible with that latest version of the "tm" package. You can do that easily within R by using the following code:

# install the latest installr package: 
install.packages("installr")

# require the latest installr package: 
require(installr)

#run the command to update R
updateR()

HT: http://www.r-statistics.com/2014/07/r-3-1-1-is-released-and-how-to-quickly-update-it-on-windows-os/

Adam D
  • 31
  • 3
1

You can use the groundhog package.

First, to find the dates you can use the cross.toc() function, which will show all publication dates for the selected packages, including R itself.

For example, to get the publication dates for tm and R:

library(groundhog) 
cross.toc(c("tm","R"))

You will get something like this:

132    3.6.1 2019-07-05       R
133    3.6.2 2019-12-12       R
134    0.7-7 2019-12-13      tm
135    3.6.3 2020-02-29       R
136    4.0.0 2020-04-24       R

If you are using R 3.6.1 you would choose a date after 2019-07-05, if you wanted the version 0.7-7 of tm a date after 2019-12-13, and then load that version with

groundhog.library('tm', '2019-12-15')