R and R packages：library directories setting and packages installation (1)

R and R packages installation

1. Installing R under Unix-alikes :

R will configure and build under most common Unix and Unix-alike platforms.

2. add-on packages

• Default packages

• Managing libraries

• Installing packages

• Updating packages

• Removing packages

• Setting up a package repository

• Checking installed source packages
  It is helpful to use the correct terminology(术语). A package is loaded from a library by the function library(). Thus a library is a directory containing installed packages; the main library isR_HOME/library, but others can be used, for example by setting the environment variableR_LIBS or using the R function.libPaths(). To avoid any confusion you will often see a library directory referred to as a ‘library tree’.

2.1 default packages

The set of packages loaded on startup is by default

> getOption("defaultPackages")
[1] "datasets"  "utils"     "grDevices" "graphics"  "stats"     "methods"

(plus, of course, base) and this can be changed by setting the option in startup code (e.g. in ~/.Rprofile). It is initially set to the value of the environment variable R_DEFAULT_PACKAGES if set (as a comma-separated list). Setting R_DEFAULT_PACKAGES=NULL ensures that only package base is loaded.

Changing the set of default packages is normally used to reduce the set for speed when scripting: in particular not using methods will reduce the start-up time by a factor of up to two（时间缩短两倍）. But it can also be used to customize R,(自定义) e.g. for class use. Rscript also checks the environment variable R_SCRIPT_DEFAULT_PACKAGES; if set, this takes precedence（优先） over R_DEFAULT_PACKAGES.

2.2 managing libraries :

R packages are installed into libraries, which are directories in the file system containing a subdirectory for each package installed there.

R comes with a single library, R_HOME/library which is the value of the R object‘.Library’ containing the standard and recommended27 packages. Both sites and users can create others and make use of them (or not) in an R session. At the lowest level ‘.libPaths()’ can be used to add paths to the collection of libraries or to report the current collection.

R will automatically make use of a site-specific library R_HOME/site-library if this exists (it does not in a vanilla R installation(在原始的R安装当中不存在)). This location can be overridden by setting· .Library.site’ inR_HOME/etc/Rprofile.site, or (not recommended) by setting the environment variable R_LIBS_SITE. Like ‘.Library’, the site libraries are always included by ‘.libPaths()’.

Users can have one or more libraries, normally specified by the environment variable R_LIBS_USER. This has a default value (to see it, use ‘Sys.getenv(“R_LIBS_USER”)’ within an R session), but that is only used if the corresponding directory actually exists (which by default it will not).

BothR_LIBS_USER and R_LIBS_SITE can specify multiple library paths, separated by
colons (semicolons on Windows).

2.3 Installing Packges

• 2.3.1 Customizing package compilation
• 2.3.2 Multiple sub-architectures
• 2.3.3 Byte-compilation
• 2.3.4 External software

2.3.1 Customizing package compilation

The R system and package-specific compilation flags can be overridden or added to by setting the appropriate Make variables in the personal file HOME/.R/Makevars-R_PLATFORM (but HOME/.R/Makevars.win or HOME/.R/Makevars.win64 on Windows), or if that does not exist, HOME/.R/Makevars, where ‘R_PLATFORM’ is the platform for which R was built, as available in the platform component of the R variable R.version. The full path to an alternative personal file can be specified via the environment variable R_MAKEVARS_USER.

Package developers are encouraged to use this mechanism to enable a reasonable amount of diagnostic messaging (“warnings”) when compiling, such as e.g. -Wall -pedantic for tools from GCC, the GNU Compiler Collection, or for clang.

Note that this mechanism can also be used when it necessary to change the optimization level whilst(同时) installing a particular package. For example ：

## for C code
CFLAGS = -g -O -mtune=native
## for C++ code
CXXFLAGS = -g -O -mtune=native
## for fixed-form Fortran code
FFLAGS = -g -O -mtune=native

There is also provision(条款、规定) for a site-wide Makevars.site file under R_HOME/etc (in a sub-architecture-specific directory if appropriate). This is read immediately after Makeconf, and the path to an alternative file can be specified by environment variable R_MAKEVARS_SITE.

Note that these mechanisms do not work with packages which fail to pass settings down to sub-makes, perhaps reading etc/Makeconf in makefiles in subdirectories. Fortunately such packages are unusual.

2.3.2Multiple sub-architectures

When installing packages from their sources, there are some extra considerations on installations which use sub-architectures. These are commonly used on Windows but can in principle be used on other platforms.

When a source package is installed by a build of R which supports multiple sub-architectures, the normal installation process installs the packages for all sub-architectures. The exceptions are :

Unix-alikes
where there is an configure script, or a file src/Makefile.

Windows
where there is a non-empty configure.win script, or a file src/Makefile.win (with some exceptions where the package is known to have an architecture-independent configure.win, or if --force-biarch or field ‘Biarch’ in the DESCRIPTION file is used to assert so).

In those cases only the current architecture is installed. Further sub-architectures can be installed by

R CMD INSTALL --libs-only pkg
using the path to R or R --arch to select the additional sub-architecture. There is also R CMD INSTALL --merge-multiarch to build and merge the two architectures, starting with a source tarball.

2.3.3Byte-compilation

As from R 3.6.0, all packages are by default byte-compiled.

Byte-compilation can be controlled on a per-package basis by the ‘ByteCompile’ field in the DESCRIPTION file.

2.3.4External software

Some R packages contain compiled code which links to external software libraries. Unless the external library is statically linked(静态链接) (which is done as much as possible for binary packages on Windows and macOS), the libraries have to be found when the package is loaded and not just when it is installed. How this should be done depends on the OS (and in some cases the version).

For Unix-alikes except macOS the primary mechanism is the ld.so cache controlled by ldconfig: external dynamic libraries recorded in that cache will be found. Standard library locations will be covered by the cache, and well-designed software will add its locations (as for example openmpi does on Fedora). The secondary mechanism is to consult the environment variable LD_LIBRARY_PATH. The R script controls that variable, and sets it to the concatenation of R_LD_LIBRARY_PATH, R_JAVA_LD_LIBRARY_PATH and the environment value of LD_LIBRARY_PATH. The first two have defaults which are normally set when R is installed (but can be overridden in the environment) so LD_LIBRARY_PATH is the best choice for a user to set.

The danger with any of the methods which involve setting environment variables is of inadvertently masking a system library(无意间掩盖了系统库). This is less for DYLD_FALLBACK_LIBRARY_PATH and for appending to PATH on Windows (as it should already contain the system library paths).

2.4 updating packages

The command update.packages() is the simplest way to ensure that all the packages on your system are up to date.
An alternative interface to keeping packages up-to-date is provided by the command packageStatus(), which returns an object with information on all installed packages and packages available at multiple repositories. The print and summary methods give an overview of installed and available packages, the upgrade method offers to fetch and install the latest versions of outdated packages.
One sometimes-useful additional piece of information that packageStatus() returns is the status of a package, as"ok", "upgrade" or "unavailable"(in the currently selected repositories).

2.5 removing packages

Packages can be removed in a number of ways. From a command prompt they can be removed by

R CMD REMOVE -l /path/to/library pkg1 pkg2 …

From a running R process they can be removed by

> remove.packages(c("pkg1", "pkg2"),
                  lib = file.path("path", "to", "library"))

Finally, one can just remove the package directory from the library.

2.6 Setting up a package repository

Utilities such as install.packages can be pointed at any CRAN-style repository, and R users may want to set up their own. The ‘base’ of a repository is a URL such as https://www.stats.ox.ac.uk/pub/RWin/: this must be an URL scheme that download.packages supports (which also includes ‘https://’, ‘ftp://’ and ‘file://’). Under that base URL there should be directory trees for one or more of the following types of package distributions:

"source": located at src/contrib and containing .tar.gz files. Other forms of compression can be used, e.g. .tar.bz2 or .tar.xz files. Complete repositories contain the sources corresponding to any binary packages, and in any case it is wise to have a src/contrib area with a possibly empty PACKAGES file.
"win.binary": located at bin/windows/contrib/x.y for R versions x.y.z and containing .zip files for Windows.
"mac.binary": located at bin/macosx/contrib/4.y for the CRAN builds for macOS for R versions 4.y.z, containing .tgz files.
"mac.binary.el-capitan": located at bin/macosx/el-capitan/contrib/3.y for the CRAN builds for R versions 3.y.z, containing .tgz files.

2.7 Checking installed source packages

run R CMD check on an installed package, particularly on a platform which uses sub-architectures. The outline of how to do this is, with the source package in directory pkg (or a tarball filename):

R CMD INSTALL -l libdir pkg > pkg.log 2>&1
R CMD check -l libdir --install=check:pkg.log pkg

Where sub-architectures are in use the R CMD check line can be repeated with additional architectures by

R --arch arch CMD check -l libdir --extra-arch --install=check:pkg.log pkg

where--extra-arch selects only those checks which depend on the installed code and not those which analyse the sources. (If multiple sub-architectures fail only because they need different settings, e.g. environment variables,--no-multiarchmay need to be added to the INSTALL lines.) On Unix-alikes the architecture to run is selected by --arch: this can also be used on Windows with R_HOME/bin/R.exe, but it is more usual to select the path to the Rcmd.exe of the desired architecture.

So on Windows to install, check and package for distribution a source package from a tarball(压缩包) which has been tested on another platform one might use

.../bin/i386/Rcmd INSTALL -l libdir tarball --build > pkg.log 2>&1
.../bin/i386/Rcmd check -l libdir --extra-arch --install=check:pkg.log pkg
.../bin/x64/Rcmd check -l libdir --extra-arch --install=check:pkg.log pkg

where one might want to run the second and third lines in a different shell with different settings for environment variables and the path (to find external software, notably for Gtk+).

R CMD INSTALL can do a i386 install and then add the x64 DLL from a single command by R CMD INSTALL --merge-multiarch -l libdir tarball
and --build can be added to zip up the installation.

reference :
[1] R Installation and Administration