14 Package States

14.1 Introduction

In this chapter we describe the five states of a package, and the functions in "devtools" that allow you to generate such states. I will walk you through these states without diving very deep into more subtle details. To know more about the different states of a package, see r-pkgs: Package structure.

14.2 Package States

The creation process of an R package can be done in several ways. Depending on the modus operandi that you choose to follow, it is possible for a package to exist in five different states:

  • Source
  • Bundled
  • Binary
  • Installed
  • In-memory
Five possible states of a package

Figure 14.1: Five possible states of a package

14.2.1 Source Package

The starting point is always a source package. This is basically the directory (i.e. folder) containing the subdirectories and files that form your package. You can think of this state as a package in a raw stage. From a source package, you can transition to more “mature” (less raw) states.

Source package

Figure 14.2: Source package

14.2.2 Bundled Package

The next immediate state (although not mandatory) is a bundled package. This involves wrapping the source package into a single compressed file with extension .tar.gz. What exactly is this file? A .tar file, also known as “tarball”, is a standard format in the Unix/Linux environment, short for Tape ARchive. In turn, a .gz file is simply the type of compression. Therefore, a .tar.gz file is a compressed tarball.

Bundled package (tarball)

Figure 14.3: Bundled package (tarball)

To generate a bundled package from a source package, you can use the "devtools" function build(). This will combine the necessary components in a single file, and gz-compress it for you.

When/how do you use a .tar.gz package? In a not so distant past, this was the default option that I would use to share a package with one of my colleagues, via email, without passing through CRAN. I would took the bundled package of an experimental version and email it to one or more friends so they could install it in their machines. They would simple need to download the .tar.gz file, and then use install.packages() with the filepath of the bundled package.

Nowadays you don’t really need bundled packages that much, especially with file-sharing and file-hosting services like GitHub, Google Drive, Dropbox, etc.

14.2.3 Binary Package

A package in binary form is another type of state for a package. This is another type of compressed file that is platform specific, and depends on the operating system you are working with (e.g. Mac/Linux, Windows).

Binary package (platform specific)

Figure 14.4: Binary package (platform specific)

To give you another description of the idea of a binary package, let me use the excellent metaphor written by David Eaton in the Quora forum.

The package that you want to install is like a 3-course meal.

The binary package is pretty much the food itself. That’s the thing you want to eat. It’s been specifically prepared for a guest based on her requirements (spiciness, temperature, intolerance to certain ingredients, etc).

The binary is the set of instructions that your computer understands how to run in order to make the software work. It’s been specifically tailored for a particular type of computer operating system.

14.2.4 Installed Package

An installed package is a decompressed binary file that has been unwrapped into an actual package library.

Installed package (decompressed binary)

Figure 14.5: Installed package (decompressed binary)

Keeping with the metaphor of the 3-course meal, an installed package is associated with an installer. An installer is like the waiter, getting your food and preparing everything for you to eat it: plates, glasses, cutlery, napkins, portions of fodd, etc. The installer basically gets your food ready for you to eat it. An installer does prep-work on your computer. While the binary may have all the instructions it needs, the installer may need to perform some set-up tasks.

To install a package with "devtools", you use the install() function. You can use this function to take a package in the form of source, bundled, or binary, to install it in your computer.

14.2.5 In-memory Package

Lastly, in order to use an installed package you need to load it into memory. This is done with the library() function.

In-memory package (loaded to be used)

Figure 14.6: In-memory package (loaded to be used)

14.2.6 Remarks

During the development of a package, you always start at the source level, and eventually make your way to an installed version. In theory, the building process would consist of the following flow: source -> bundle -> binary -> installed —> in-memory. In practice, however, you can take some detours and shortcuts from source to installed.

Theoretical flow of package states

Figure 14.7: Theoretical flow of package states


Make a donation

If you find this resource useful, please consider making a one-time donation in any amount. Your support really matters.