R package build failed on Unix machines due to lack of GSL - GNU Science Library

Question

I ran into a particularly nasty problem while developing the R package. My own package, called ggstatsplot ( https://github.com/IndrajeetPatil/ggstatsplot ), depends on userfriendlyscience , which depends on another package called MBESS , which itself ultimately depends on another package called gsl . There is no problem installing ggstatsplot on a Windows machine (as evaluated by the AppVeyor continuous integration AppVeyor : https://ci.appveyor.com/project/IndrajeetPatil/ggstatsplot ).

But whenever a package needs to be installed on Unix machines, it throws an error that ggstatsplot cannot be downloaded, because userfriendlyscience and MBESS cannot be downloaded, because gsl cannot be downloaded. The same can be found in the continuous integration platform Travis with Unix virtual machines, where the assembly fails package ( https://travis-ci.org/IndrajeetPatil/ggstatsplot ).

Now, one way to solve this problem for a user on a Unix machine is to configure GSL (as described here: installing the R gsl package on a Mac ), but I cannot expect every ggstatsplot user to go through the complicated gsl configuration process. I want them to just run install.packages("ggstatsplot") and do with it.

So, I would really appreciate it if someone could offer me useful tips on how I can simplify my life in the package by removing this problem in its source. Is there something I have to include in the package itself that takes care of this on behalf of the user?

Answer 1

This may not have a satisfactory solution through changes to your R package (I'm not sure anyway). If the authors of the gsl package (including a former R Core member) did not configure it to avoid installing the linux package before req, there may be a good reason for this.

But there may be a consolation that most R + Linux users realize that some R packages first require the installation of Linux base libraries (for example, via apt or dnf / yum ).

The main problem: simplifying installation by users

Try to be very clear in the GitHub readme and CRAN INSTALL file . The gsl package has decent CRAN guidance . This leads to the following bash code:

 sudo apt-get install libgsl0-dev 

The best example of transparent (linux pre-req package) documentation I've seen is the curl and sf packages. sf The CRAN page contains only the names of people from 3 libraries, but GitHub provides accurate bash commands for the three main distribution branches. The package also curls very well (e.g. CRAN and GitHub ). For example, it provides the following explanation and bash code:

Installation from source on Linux requires libcurl . On Debian or Ubuntu, use libcurl4-openssl-dev :

 sudo apt-get install -y libcurl-dev 

Ideally, your documentation describes how to install the gsl linux package on multiple distributions.

Disclaimer: I have never developed a package that directly requires a Linux package, but I use a lot of them. In case more examples help, this document contains a script that I use to install on new Ubuntu machines. Some commands were specified explicitly in the package documentation; some of them have little or no documentation and require research.

Secondary Problem: Installing on Travis

the travis user configuration file obviously installs several binaries at once (including gsl ), unlike the current version of ggstatsplot .

Alternatively, I am more familiar with the story that Travis installed the linux package, as shown by the curl config file . As a bonus, this probably more accurately repeats what typical users do on their machines.

 addons: apt: packages: - libcurl4-openssl-dev 

Follow 2018-03-13 Indrajeet and I modified the travis file to make it work. Two sections have been changed in the yaml file :

• The libgsl0-dev entry libgsl0-dev been added in the packages section (similar to the libcurl4-openssl-dev entry above).
• The packages were listed in the r_binary_packages section, so they are installed as binary files. The assembly was disabled after 50 minutes, and now up to 10 minutes. In this particular package, the r_binary_packages section was nested in the Linux part of the Travis matrix, so it would not interfere with its two OS X jobs on Travis.