Introduction

If you plan to use the agrometeoR package, you must know that this packages relies on other packages that are sometimes still in development versions. For example, the implementation of gstat into mlr required to perform kriging interpolation while benefiting of the mlr unified interface for algorithms benchmarking is not available on CRAN.

The packages that are required by a specific package are called dependencies and these are listed into the DESCRIPTION file of a package.

When a package is installed, its dependencies will also be installed by R if not yet available on the machine. Sometimes a package may require a minimum version number of one of its dependencies. This might lead to conflict with versions already installed on the computer. To solve this conflict you might need to uninstall a version of a dependency that has been proven to work for another package and/or analysis resulting in potential breaks of your previously working code.

As shown in its DESCRIPTION file, the agrometeoR packages requires multiples dependencies with minimal version number to work. If you want to make sure that your project (analysis our app) that relies on the agrometeoR packages works and don't break other projects that require the same dependencies, we strongly recommand you to use packrat !

Important note :

R package dependencies we are talking about into this article means R packages required for a specific R package to work. We don't talk about linux dependencies ! As these might be as tricky as R paclage dependencies, we strongly suggest you to learn more about Docker to create containerized operating system configurations.

To quote packrat official website :

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 has been built to avoid dependencies intercompatability issues. Think of it as virtual environement similar to pypenv. In this article, we will learn how to get the most out of it in the context of an analysis/project that requires the agrometeoR package. For a detailed explanation about packrat, please visit the official website.

Packrat vs. non-packrat project

In a non-packarat project, R install the libraries in a specific folder that is made available to all of your R projects. In a Linux environment, the R command .libPaths() tells you where is located this folder. By default it is located at /usr/local/lib/R/site-library. In a packrat project, R install the libraries in a private library which is only available to this specific project and which is located into the project directory. This ensures that there is no dependencies collision between projects.

Starting a new project that requires agrometeoR : the packrat way

Let say you want to start a new R project (an analysis our an app) that requires agrometeoR. What you would normally do, is to install the package using devtools::ìnstall_github("pokyah/agrometeoR") and load the package using library(agrometeoR). Doing so R will install and load agrometeoR to and from your system wide folder (/usr/local/lib/R/site-library).

Now, lets work the packrat way !

Once you have created a new folder for your project and cd into it, you first must install packrat globally.

install.packages("packrat")

Once installed, you make your project a packrat project by initializing packrat :

packrat::init()

This command will create a packrat folder at the root of your project. This is the private library of your project where all of the required packages will be installed. Once packrat is initialized, R will never look at the packages that are globally installed. So if you already had some libraries previously installed, you will need to reinstall those into your project private library

And how does R knows that the current project is a packrat one ? R, simply adds a new line to your project .Rprofile file telling R to use the project private library when installing and loading packages. Hence, each time R is loaded from this project, it will read this .Rprofile file and understand it must work in packrat mode.

Now, we can install agrometeoR in this packrat context :

devtools::install_github("pokyah/agrometeoR")

R now installs agrometeoR and all its dependencies listed into its DESCRIPTION file into your project private library.

You can now use all of the functions of the agrometeoR package knowing they will work and that this new installation will not break previously existing code relying on your global R packages library.

Keeping track of your dependencies versions

Once you are into a packrat project, packrat also creates and updates a packrat.lock file where it stores all the informations about your dependencies : name, repository, version number, etc. This file is extremely useful for reproductibility as it lists all the information required to reconstruct the exact same environment that was used to conduct an analysis. It is used by packrat itself if you use packrat::restore().

packrat if you use the agrometeoR package

If you plan to use the agrometeoR package into your project

http://distancesampling.org/developer/develop/dev-packrat.html https://github.com/r-lib/pkgdown/issues/488

https://rdrr.io/github/rstudio/packrat/man/packify.html in case there is a need for packrat mode on on each startup



pokyah/agrometeoR.extras documentation built on May 27, 2019, 2:07 p.m.