How to install R package binaries on Linux just like on Windows? - r

When I run install.packages("somepkg") on Linux (Ubuntu mostly), the installation process invovled building the R package from source which can be time consuming. Also it can be prone to failure due to missing development related Linux packages.
Is there a way to install compiled binaries like on Windows? I heard that it can be done, but couldn't find an easy to understand resource. Hope by asking here I will make the answer (if it exists) more googlable.

It depends on whether binaries exist. Which, in turn, depends on which Linux distro and version you are running.
For Ubuntu 18.04 (and later, as they are compatible), you can use the Rutter PPAs which cover over four thousand CRAN package. This is described (albeit very briefly) at the top of this README at CRAN.
I also blogged about that (a few times) below my r4/ tag -- and because it didn't really "stick" amplified it again with short video plus slides, see this post. The video runs for about 5 mins during which we install rstan and tidyverse as binaries each with just one command and it takes about a good minute each (depending on bandwidth and disk speed, of course) pulling all dependencies in pre-built and in a fail-safe manner.
If this matches your needs, give it a try and please come to to the r-sig-debian list for questions.
If you are on a different Linux flavor then I unfortunately less sure if a comparable service exists.
Edit on 2020-09-17 As this was just upvoted and I was thus reminded of it, you now have better options and can get Linux binaries via install.packages("pkgname"). One way is RSPM, the other is BSPM. I have a first comparison blog post comparing both here (even with animated gif movies ;-)) and should be able to say more about BSPM "soon".
Edit on 2022-08-03 And going beyond RSPM and BSPM is the newer r2u which has been up for a few months and is currently serving around two thousand binaries a day. It is the best approach for binaries on Ubuntu LTS installations (currently: 20.04 and 22.04). See r2u for more including demos.

Related

Packrat::restore() for system dependencies

I was developing a shiny-app on a Windows machine in Rstudio. Now I need to develop it on a Linux machine and later on will need to deploy it on a server. Because of the need to run the app across platforms, I was looking into some environment control application so that I don't have to tune and reinstall the needed packages manually.
I tried to use Packrat for this purpose. I made a snapshot on my Windows machine, copied and pasted the project to my Ubuntu, reopened the project on RStudio, installed Packrat and the restore of the packages ran automatically. Then I ran into an issue that some of the packages that requires system dependencies were not installed automatically, e.g. rgdal and jqr. Therefore, I had to manually install those system dependencies manually in a terminal (it took me a while because there were about 10 of them that requires extra system dependencies).
I am wondering if there is an easier way to just automatically handle this. Later on, I will need to work with a system administer to deploy the app to the server. I am wondering if Packrat has the capability of automatically installing system dependencies on Linux machine/server. If anyone has encounter this issue before, or have other better options, please let me know!
Thank you!
Hello and welcome to StackOverflow.
You are facing a question that is actually much harder to tackle than you may think at first---deployment of complex R package dependencies across different operating systems is a truly hard and, truth be told, unsolved problem!
You can of course use packrat and renv for R package dependencies and snapshots of particular versions. But this does not do anything for system-level dependencies which are simply taken as "given". So no to just transfering to another box and saying "abracadabra". Sorry!
The closest we all may have gotten to fixing this may be Docker where you can create a portable unit of execution that can be deployed whereever Docker run: Windows, macOS, different Linux flavours, ... as it encodes everything.

How to replicate the package check time performed on CRAN?

I've been trying to reduce the check time on a package I am submitting to CRAN. On my local machines, check time is somewhere between a minute (i7 CPU) and 2 minutes (i5 CPU). However, CRAN reviewers keep pointing out the check time is over 10 minutes. The only way I could find to reproduce such long check times is by uploading my package to http://win-builder.r-project.org/, where it indeed takes > 600 s to check.
I wish I could reproduce this check time locally so I am not dependent on a remote solution. The only difference I can see between Win builder and my local machine is the OS (Win vs. Linux) and how Win builder seems to be doing multiarch checks (i386 and x64).
I am not sure how to reproduce this locally. I have tried R CMD check with seemingly-relevant switches like --multiarch and --force-multiarch but it doesn't seem to be doing anything differently. I guess I have to install some extra packages like r-cran-i386 or whatever, but I couldn't find anything of the sort in my repositories ("R" can be such a PITA of a search expression) and the instructions on README files like the one on https://cran.r-project.org/bin/linux/ubuntu/ didn't get me far enough.
I am already using --as-cran, and am aware of solutions like this, though I think installing R i386 on a separate VM containing a 32-bit OS defeats the purpose of what I am trying to accomplish.

Checking an R-devel-linux error for my CRAN package using my MacBookPro

I have a CRAN package that has inputenc errors when creating vignette PDF outputs in a strict Latin1 locale. The check results have errors for flavor
r-devel-linux-x86_64-debian-clang, which uses LANG=en_US.iso885915. I believe I may have fixed the problem (it was a warning on my Mac). However, I feel I should check the problem on Linux as well before submitting bug fixes to CRAN. It was suggested to me that to check that my package fixes the error on LANG=en_US.iso885915, that I should run the following command on Linux:
LANG=en_US.iso88591 R CMD check
I do not have access to Linux and will not for the reasonably foreseeable future. I am trying to figure out how to run this command on my macOS Catalina (version 10.15.3). With little experience running Linux on Mac, I have been doing searches online, with an example forum here. There are some negatives discussed there, including the lack of necessity of running Linux on Mac (usually), installation of Linux restraints on latest MacBooks, and virtual machines not truly representing what Linux can do.
I decided it may be helpful for me to ask here on SO. I do not have too much storage left on my Mac and I would likely delete any Linux installations quickly since I will likely not need them outside of this one issue. I also do not have much experience installing virtual machines and Linux. I also hope to avoid any other risks I may not even be aware of to my computer.
What is the best way (convenient, low risk, quick, low storage requirements) you may know for someone in my position to check this recommended command (LANG=en_US.iso88591 R CMD check) with access to simply my MacBook Pro (Retina, 13-inch, Early 2015)? Thank you for sharing suggestions!

Pinning R package versions

How do you best pin package versions in R?
Rejected strategy 1: Pin to CRAN source tar.gzs
Doesn't work if you want to pin it at the latest version since CRAN does not put the tip version in the archive (duh)
Rejected strategy 2: Use devtools
Don't want to, because it takes ages to compile and adds lots of stuff I don't want to use
Rejected strategy 3: Vendor
Would rather avoid having to copy all source
To provide a little bit more information on packrat, which I use for this purpose. From the website.
R package dependencies can be frustrating. Have you ever had to use
trial-and-error to figure out what R packages you need to install to
make someone else’s code work–and then been left with those packages
globally installed forever, because now you’re not sure whether you
need them? Have you ever updated a package to get code in one of your
projects to work, only to find that the updated package makes code in
another project stop working?
We built packrat to solve these problems. Use packrat to make your R
projects more:
Isolated: Installing a new or updated package for one project won’t
break your other projects, and vice versa. That’s because packrat
gives each project its own private package library. Portable: Easily
transport your projects from one computer to another, even across
different platforms. Packrat makes it easy to install the packages
your project depends on. Reproducible: Packrat records the exact
package versions you depend on, and ensures those exact versions are
the ones that get installed wherever you go.
Packrat stores the version of the packages you use in the packrat.lock file, and then downloads that version from CRAN whenever you packrat::restore(). It is much lighter weight than devtools, but can still take some time to re-download all of the packages (depending on the packages you are using).
If you prefer to store all of the sources in a zip file, you can use packrat::snapshot() to pull down the sources / update the packrat.lock and then packrat::bundle() to "bundle" everything up. The aim for this is to make projects / research reproducible and portable over time by storing the package versions and dependencies used on the original design (along with the source code so that the OS dependency on a binary is avoided).
There is much more information on the website I linked to, and you can see current activity on the git repo. I have encountered a few cases that work in a less-than-ideal way (packages not on CRAN have some issues at times), but the git repo still seems to be pretty active with issues/patches which is encouraging.

Writing an R package that is different per architecture

I am writing an R package in which you can make networks and output them in different file-types. I found the package SVGRTipsDevice which can be used to create SVG pictures containing tooltips and hyperlinks, which I really like. I have included this in my package as one of the options to output in, making it not an essential part of my package, but a part of it nonetheless (one that I want to keep).
The problem now is, that this package is for 32bit users only. Because my package depends on it 64bit users are not able to install it. it seems that I either have to make my package 32bit-only as well or remove the SVG abilities (currently I chose the latter to upload to CRAN, with a link to the full package on my site).
Is there any way to do this differently? Like making the package installable for anyone but only make the SVG functionality available for 32bit users?
easiest way I can think of is to check Sys.info() for the machine type:
So on my machine:
Sys.info()["machine"]
machine
"x86_64"
EDIT I believe that tells us the architecture of the hardware, not whether R is 32 or 64 bit. So if a user had 64 bit hardware and was running 32 bit R, the above code would still return x86_64 As Sacha pointed out to me, a better solution is to run:
R.Version()$arch
[1] "x86_64"
So you can see I'm running a 64 bit OS AND I am running the 64 bit version of R.
Packages listed in the Suggests: or Enhances: field of the DESCRIPTION file of your package do not need to be installed on the user's system for your package to be installed, so that 32/64 bit users can install your package. Rather than testing for bit-ness, you might ok <- suppressWarnings(require(SVGToolTips))), maybe in .onLoad or similar.
You could make a packagename-32bit package also with the extra functionality.

Resources