The new R 3.0.0 requires that all contributed packages are reinstalled. Two questions:
Does this also mean that software that calls R, e.g. rapache, need to be recompiled after R has been upgraded?
Are the new builds backward compatible? E.g. if an r-cran-xxx package has been compiled using r-base-dev 3.0.0, can this package be loaded in R 2.15? Or do we need to distribute separate binary packages for R 2.15 and R 3.0.0?
This is really a question for r-devel, or as you use our Debian / Ubuntu package terminology, r-sig-debian.
In short:
Question 1 is AFAICT a no. The R C API did not change. The design of Rapache heavily influenced our much smaller littler r, and r runs just fine on my Ubuntu box after installing R 3.0.0 from Michael's builds based on my packages. Even though littler (see r --version) was built against R 2.15.2.
Question 2 is a no, and that is no change. R always moves "forward in time", not backwards. Just how we need package rebuilds when NAMESPACES were added, and when the help format changed. So if you have N different R versions with M different ABIs for packages, you may need M trees and manage your libPaths. Nothing new here.
Related
I am running R 3.6.1 on a Mac Mini running Sierra and a MacBook Pro running El Capitan. I normally get all the R packages that I need from CRAN or github and use them without issues, but I am trying to install and use an R package (NicheMapR) that requires a fortran compiler and this is giving me issues. Even after installing gfortran, the R package still does not work (the fortran code seems to be compiled but the package installation fails). The package developer suggested that installing R via homebrew might solve the problem. On the contrary, my hunch is that it would lead to a world of pain, to quote Walter from the Big Lebowski. My questions are:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Can the two versions coexist?
Is the homebrew version going to affect the regular one?
Finally: is homebrew going to help or will it simply open a whole
new can of worms?
Many thanks in advance.
Yes, installing from homebrew is a recipe for pain. It's specifically recommended against by the official CRAN binary maintainer see his remarks from March 2016 on r-sig-mac.
Regarding your questions, this can be summarized as:
What is the advantage of a homebrew version of R for MacOSX over the "regular" version installed from CRAN?
Positives: Select your own BLAS and easily work with geospatial tools.
Downsides: Always needing to compile each R package.
Can the two versions coexist?
Yes. The homebrew version installs into a different directory. But, watch out for library collision (see next question). However, you will have to deal with symbolic linking regarding what version of R is accessible from the console and you will also need to look into using RSwitch to switch between R versions.
Is the homebrew version going to affect the regular one?
Yes, if the library paths overlap. There will be problems regarding package installation and loading. Make sure to setup different library paths. To do so, please look at the .libPaths() documentation.
Finally: is homebrew going to help or will it simply open a whole new can of worms?
Yes and no. Unless you know what you're doing, opt for the CRAN version of R and its assorted goodies.
I want to install a package that is listed in https://cran.r-project.org/web/packages/available_packages_by_name.html as available in CRAN, but when I check in R the install packages menu or the available.packages() command, I can't see the package there.
Do I need to do something different to install those packages? Why aren't those packages available?
The packages I'm interested on are WikipediR ( https://cran.r-project.org/web/packages/WikipediR/index.html ), WikidataR and WikipediaR.
If it matters, I'm using R 2.15.0 in Windows XP.
See the documentation for ?available.packages...
By default, the return value includes only packages whose version and
OS requirements are met by the running version of R, and only gives
information on the latest versions of packages.
In other words... your R 2.15 is likely too old for the package you are looking to download.
You can try to download the package source manually add the package to the package library usually found somewhere like "win-library/2.15/" but like Cory mentioned it is likely that the older version of R does not support the package build.
The advice given so far is a bit incomplete although I do agree you need to update your R version if you want to use these packages. Looks like they don't need compilation so you might have been able to either install from a local copy or drop R code in, but critically they depend on httr which requires R 3.0.0 or above. They were released only relatively recently, so there will be no Windows binaries from back in 2012. (Your copy of R is from 30-Mar-2012.) Look in the DESCRIPTION file which is presented in a nice web format at the CRAN/package listing:
https://cran.r-project.org/web/packages/WikidataR/index.html
Imports: httr, jsonlite, WikipediR
Suggests: testthat, knitr, pageviews
# only one version of these two
https://cran.r-project.org/src/contrib/Archive/WikidataR/WikidataR_1.0.0.tar.gz
https://cran.r-project.org/src/contrib/Archive/WikipediaR/WikipediaR_1.0.tar.gz
# pick one of these
https://cran.r-project.org/src/contrib/Archive/WikipediR/
For over a year now, I've been afraid to update my version of R for fear of losing the "rgdal" package...which when I first started working with R on my mac (and maybe still?), had to be installed from source/ could not be installed via the package installer from within R. That was complicated and I had to seek help from a more experienced R user than myself in order to get this package which is critical for me.
But I've finally decided that I need to take the risk and update R. I used the following instructions:
#--run in the old version of R
setwd("C:/Temp/")
packages <- installed.packages()[,"Package"]
save(packages, file="Rpackages")
Followed by this in the new version:
#--run in the new version
setwd("C:/Temp/")
load("Rpackages")
for (p in setdiff(packages, installed.packages()[,"Package"]))
install.packages(p)
found in this post:
Painless way to install a new version of R?
This seems to have worked (e.g. I can open up libraries that aren't included in the base install...including rgdal) but I have the following questions in order to better understand this whole process:
1) Is it the case that in following this approach, I essentially saved a list of all the R packages I had previously installed in my old version, then (from within the new version) determined the SET of packages that differed from the set of base libraries in the new version and told R to install packages belonging to this SET?
2) If the above is true, then does this approach negate the need to update my packages after (e.g. by installing them from within the new version, the newest versions are installed)?
3) The other approach that seems to be common out there (and that is recommended in one of the responses to the post above) is to set up things so that all packages get saved to a directory outside of R and then change the settings (in the .Renviron file or whatever the appropriate file is) to always look for packages in this external directory... I'm wondering why this approach is favoured by some people? Is it because this approach means that after updating R everything is just ready to go (e.g. if one is willing to work with un-updated packages)? I'm confused because if one still has to use update.packages() after installing a new version of R, doesn't this just more or less amount to re-installing them? What are the advantages?
4) Are there packages that I need to worry about if I do go the install route (and not the save to external directory then update route)? R did give me a warning that indicates that four of my packages are not available for the latest version (R. 3.0.3). I'm assuming that if I need to use these packages, I must temporarily just revert to an older version of R. Is this all correct?
Thank you in advance for the help!
1) Yes.
2) The newly installed packages will be at the latest version, but there is no harm in running update.packages(ask=FALSE, checkBuilt=TRUE) afterward just be be sure everything is up to date.
3) I've not seen anyone suggest this particular approach, though a similar process is suggested in the R for Windows FAQ that consists of 1) installing the new version 2) copying the packages from the library folder of the old version to the library folder of the new version and 2) running update.packages(checkBuilt=TRUE, ask=FALSE). I don't think there are any clear advantages to doing it this way vs. the installed.packages()... way.
4) All methods under discussion are limited to CRAN packages, so things that you installed from e.g., bioconductor will not be covered. Also packages removed from CRAN will not be covered, you will either have to use an older version of R or build and install them manually.
I'm trying to use R through SPSS syntax (I'm using SPSS 18 on windows 7) which requires installing a special plugin: PASWStatistics_RPlugIn_1802_win32.exe. Also I had to install an older version of R(2.8.1 - required by my older version of SPSS - i like it better than the new ones). The plugin now works, R (both versions) works, but Rstudio stopped working and won't start even after uninstalling and re-installing.
Does anyone have any similar experience and could suggest a solution?
The following link specifies how you can configure Rstudio to work with a specific R version you have installed:
http://www.rstudio.com/ide/docs/advanced/versions_of_r
Just install R 2.8 and 2.14 and let spss use one, and Rstudio another.
You are taking a risk by using old versions of spss and R (bugs that have been fixed in newer versions, decreased performance, possible incompatibility with other software e.g. R packages, missing functionality).
You can have multiple versions of R installed at the same time - I have five. The current version of Statistics, 21, goes with R2.14. I don't know how Rstudio determines which version to use. You might need to reset the R environment variables or your path settings.
According to this link
only installing the following package in Ubuntu will speed up R significantly for certain calculations:
libatlas3gf-base
Do I have to compile from source to get this benefit? If not, do I have to reinstall R after installing this package?
Are there any other packages that are similar to this in that they can speed things up by just installing them?
The libatlas3gf-base base package will already help over the default "reference blas", but you can (if you care) do better by locally building Atlas. That is in a way the whole point of Atlas as the A and T stand for Automatically Tuned.
Now, keep in mind that a) rebuilding the package is not as trivial as just installing the base package and b) you were quite right in pointing to certain calculations. Your net time spent in R will only rarely by bound by the linear algebra operations that you can accelerate here. So for me, just installing atlas-base is usually good enough on my Ubuntu and Debian systems.