Packages, Libraries and Namespaces

The R FAQ answers the question in one entry, 7.29: a package is a standardized collection of material that extends R (code, data or documentation); a library is a place, a directory, where R knows to find the packages it can use, that is, the ones that were installed; and R is told to use a package, which means to load it and add it to the search path, by calling the function library(). So library() takes a package from a library, and the name of the function is the source of the most common mistake: library(ggplot2) does not "load a library". R Installation and Administration opens its chapter on add-on packages with the same terminology note and adds that a library directory is often called a library tree to avoid the confusion. FAQ 7.30 is the companion entry: the question "I installed a package but the functions are not there" has a one-line answer, that the package needs to be loaded with library(). Installing puts files in a library; it does not change the running session at all.

Source: R FAQ 7.29: What is the difference between package and library?

The standard packages (base, stats, utils, graphics, grDevices, datasets, methods, tools, parallel, compiler, grid, splines, stats4, tcltk) are part of the R source code and are installed with R; the recommended packages (MASS, Matrix, lattice, survival and others) are included with every binary distribution of R, and the several thousand other packages live in repositories (An Introduction to R, section 13: Packages). The first script asks the session about the difference between the folder, the installed package and the loaded one: the paths are reduced to their last component, because the folders of the machine that ran the examples are not interesting.

Source: R documentation: library

library() with no arguments returns an object of class "libraryIQR", a list whose results matrix has one row per installed package (Package, LibPath, Title), and the help page warns that its structure may change in future versions; .packages(all.available = TRUE) gives just the names and installed.packages() gives more columns (versions, dependencies, license, the Built field) but, as its help page warns, it reads several files per installed package and is slow with thousands of packages, so it is not the tool for asking whether one package is installed (see "Where older tutorials differ").

The folders that R searches are in .libPaths(), a character vector of existing directories, first one first. A call without argument reports them; a call with a character vector sets them to the existing directories of unique(c(new, .Library.site, .Library)), so the new libraries come first, then the site libraries, then the system library. The system library .Library is R’s own library folder; .Library.site is the (possibly empty) site library, site-library under R_HOME unless R_LIBS_SITE or Rprofile.site says otherwise. Since R 4.1.0 .libPaths() has the argument include.site, which leaves the site library out of the new path. The directories are normalised, so the printed form can differ from what you passed, and a directory that does not exist is dropped without a message, which is the usual reason why a library "disappears" from the path after a typo.

Source: R documentation: .libPaths

At startup R builds .libPaths() from environment variables (the Startup page of this section explains where such variables can be set, and in which order the files are read): R_LIBS first and R_LIBS_USER next (both may hold several directories, separated by colons on Unix-alikes and semicolons on Windows), then the site libraries from R_LIBS_SITE, then the system library. Only directories that exist at that moment are kept. R_LIBS is unset by default; R_LIBS_USER is set by R’s startup code when it is unset or empty, to a folder in the home directory that is specific to the R version: R/<platform>-library/<x.y> on Unix-alikes (for R 4.6.1 that is ~/R/<platform>-library/4.6, where the platform is the canonical string of the build, the value of R.version$platform), R/win-library/<x.y> under LOCALAPPDATA on Windows, and Library/R/<m>/<x.y>/library for the CRAN builds on macOS, where <m> is Sys.info()["machine"], the name of the CPU architecture. Since R 4.2.0 R_LIBS_SITE is set by R the same way, so Sys.getenv("R_LIBS_USER") and Sys.getenv("R_LIBS_SITE") show the defaults from inside a session (before 4.2.0 only the user variable was). The value NULL for either variable means "no directories", and the default user library is used only if the folder exists, which by default it does not: R-admin says so, and install.packages() in an interactive session offers to create the personal library when the first library is not writable. The version-specific folder is deliberate: the compiled code of an installed package is tied to an R series (4.5.x, 4.6.x), so each minor version of R wants its own library, and upgrading R from 4.5 to 4.6 starts with an empty user library that you refill (with update.packages(checkBuilt = TRUE) the packages that were built under an older minor version count as old).

Both variables expand the specifiers %V (R version including the patch level), %v (without it), %p (the platform), %o (the operating system) and %a (the CPU architecture), and %U and %S stand for R’s own defaults, so one .Renviron line (a file of NAME=value lines, not R code) can serve several R versions:

Source: R documentation: Startup (the example ~/.Renviron)

The next script is a short probe that is run several times with different variables in the shell; it prints the library paths under the home directory (shortened with ~), how many of the other paths there are, and the last component of those others (the site and system libraries of the image). The directories are made first with mkdir.

Source: R documentation: .libPaths

The four runs, as typed in a terminal and the output of each (the script is saved as show-libs.R):

Source: R documentation: .libPaths (start-up)

The first run shows the order (R_LIBS directories first, in the order written), the second R_LIBS_USER, the third the value NULL for the user and site variables that leaves only the system library, and the fourth the rule that a user library which does not exist is not on the path. The rest is advice that has stood the test of time: keep the system library for what ships with R and put everything else in a user or project library (the installed.packages() help calls this the recommended setup of many professionals), set R_LIBS_USER in .Renviron rather than calling .libPaths() in .Rprofile (the startup page of this section explains why a profile is the wrong place for settings that child processes such as R CMD check also need), and use a project library when the versions matter (see Reproducible Environments with renv).

install.packages() is the main function: it takes the names of packages and a destination library, downloads the packages from the repositories and installs them. R Installation and Administration says that for most users it suffices to call install.packages(pkgname) when the package is on CRAN and there is Internet access; the same function installs from local files, as the next section shows. These are the arguments that matter, with the defaults from its help page:

Source: R documentation: install.packages

The installation of several source packages is done in an order that respects their dependencies. Locking keeps two installations from damaging each other: a source install locks the library by creating a directory named 00LOCK (per package, 00LOCK-<package>, when one package is installed or when Ncpus > 1) inside it, which also holds the previous version of the package so that a failed installation can restore it. If the installation fails so badly that the lock directory stays behind, nothing more can be installed into that library until the directory is removed by hand, the help page warns. Since R 3.6.0 a source installation is also staged by default: the package is installed into a temporary location under the library and moved into place when it is complete, so that other R sessions never see a half-installed package (R_INSTALL_STAGED and the --no-staged-install option turn it off). Since R 4.5.0 install.packages() and download.packages() download several packages simultaneously with libcurl, and since R 4.5.2 they consult the option download.file.method again when the method is not given.

A repository is a directory tree behind a URL that install.packages(), available.packages() and update.packages() can read, listed in getOption("repos"). CRAN is the main one (the R FAQ’s "What is CRAN?" entry describes the network of mirrors); Bioconductor is the second big one; R-universe, R-Forge and a folder of your own work the same way. A repository has up to two kinds of directories (R-admin, "Setting up a package repository"): src/contrib with the .tar.gz source packages, and for each binary type bin/<os>/<build>/contrib/<x.y> (bin/windows/contrib/4.6 for Windows, bin/macosx/sonoma-arm64/contrib/4.6 for a macOS build), each with a PACKAGES index file (optionally also PACKAGES.gz and PACKAGES.rds, which are downloaded in preference). contrib.url() builds those URLs, and the script below prints them for the three types.

Three functions form a family. old.packages() compares what is installed with what the repositories offer and returns a matrix of the packages that have a newer version (NULL when nothing is old); update.packages() does the same and installs the newer versions, asking about each package unless ask = FALSE; new.packages() lists packages in the repositories that are not installed. With checkBuilt = TRUE, a package built under an earlier minor version of R than the running one (built under 4.5 when you run 4.6) is also considered old, which is how a user library is refreshed after an upgrade of R. packageStatus() gives a richer view (the status of each installed package as "ok", "upgrade" or "unavailable", R-admin says) and download.packages() fetches the newest tarballs into a folder without installing them. remove.packages(pkgs, lib) deletes a package from a library (the first one on the path if lib is missing); R CMD REMOVE is the command-line form, and removing the package’s folder by hand also works, as R-admin notes. Since R 4.2.0 remove.packages() no longer tries to uninstall packages of priority "base". Two cautions from the help pages: update.packages() should be run before install.packages() so that the dependencies already installed are current, and passing dependencies to update.packages() is only allowed when every package to be updated is in the same library, because otherwise it is unclear where the new dependencies should go.

The second repository script shows the whole cycle in the folder repository: install shelfcore 0.1.0, check that nothing is old, publish 0.2.0 (rebuilding the index), find the old package, update it without asking, and download the tarball. The repository is the folder, so nothing in this script needs the network either.

Source: R documentation: update.packages and old.packages

old.packages() returns a character matrix with one row per package and the columns Package, LibPath, Installed, Built, ReposVer and Repository; the script shows three of them and drop = FALSE keeps the one row a matrix. download.packages() returns a two-column matrix of names and file names; for a local repository the help page says that the packages are used where they are instead of being downloaded, so the file name is the file in the repository (shown with basename()). update.packages(ask = FALSE) is convenient in a controlled project and a trap in a script: it changes the versions that later code runs against, which is the opposite of what a reproducible environment is for (the renv page covers that). R 4.6.0 made one change that matters when comparing: the Built column of installed.packages() and old.packages() now holds the full Built field of DESCRIPTION (the R version, the platform, a time stamp, the OS type), where it used to hold only the R version.

Source: R documentation: remove.packages

Everything about an installed package can be asked of the session, and almost never needs a path. The next script uses the installed shelf package; the paths are reduced with basename(), and the output of the functions that print a date, a user name or a folder is left out of the example for that reason (packageDescription("shelf") prints the Built and Packaged fields, sessionInfo() prints the platform, and neither belongs in a page that must not depend on the machine).

Source: R documentation: packageDescription and packageVersion

A few remarks on that output. packageVersion() returns a package_version, and <, >= and the other comparison operators compare versions component by component: as strings "0.10.0" > "0.9.0" is FALSE (the character comparison looks at the first differing character), as versions it is TRUE; compareVersion() returns -1, 0 or 1. packageDescription() returns the DESCRIPTION of an installed package as a list of fields (a field that is not there is NULL, as Imports is for shelf); its print method also shows the file it was read from, which is why the script uses $. find.package() returns the folder of an installed package and fails when it is missing (or returns character(0) with quiet = TRUE), system.file() finds a file inside it and returns "" when the file does not exist, and path.package() does it for attached packages only; they are the right way to locate data or templates shipped in inst/, because the folder is not the same on every machine, and they are also the cheap way to test for a package without loading it. library(help = "shelf") gives the description and the help index of the package (an object of class "packageInfo"), help(package = "shelf") opens the same in the help system, vignette(package = ) lists the vignettes and vignette("shelf", package = "shelf") shows one, browseVignettes() opens a list of them in a web browser (so it is not run here), data(package = ) lists data sets, news(package = ) shows the NEWS file and citation("shelf") gives the text to cite a package, built from inst/CITATION or from DESCRIPTION. sessionInfo() prints R’s version, the platform, the locale and the versions of the attached and the loaded-only packages; it is the first thing to paste into a bug report, and its output is not reproduced here because it contains the platform and the locale of the machine.

Source: R documentation: citation

The folder of an installed package is not a copy of its source tree. The next script shows what is there, with the two facts that the install output announced: the R code is in a lazy-load database (R/shelf.rdb and R/shelf.rdx, no .R files; objects are read from the database when they are first used, which is what makes library() fast even for packages with thousands of functions), and the functions are byte-compiled (printing one shows a <bytecode: ...> line with a memory address, so the script only tests for that line). Data sets are lazy-loaded too. The internal data of the package (sysdata.rda) has its own database pair.

Source: R Installation and Administration: Installing packages

An installed package is dead weight until something loads it. R has two separate operations, and the language of the manuals is exact about them. Loading a package means loading its namespace: R reads the code from the lazy-load database, creates the namespace environment (namespace:shelf), fills the imports that its NAMESPACE file asks for (loading the other packages' namespaces first, when they are not loaded yet), registers the S3 methods, and runs the .onLoad() hook. Attaching means making the package visible on the search path: R copies the package’s exports into a new environment named package:shelf placed at position 2 of search(), and runs the .onAttach() hook. library() and require() do both, loadNamespace() and requireNamespace() only the first, and shelf::book the first when the namespace is not loaded yet and then reads one object. An Introduction to R puts the purpose of namespaces in three sentences: they let the package writer hide functions and data that are for internal use, they prevent functions from breaking when a user or another package writer picks a clashing name, and they give a way to refer to an object within a particular package. Its example is t(), the transpose: a user may define their own t, and the namespace stops that definition from replacing the transpose in every function that calls it.

The figure draws the two operations for shelf. The three boxes on the left are calls; the middle column is what a loaded package consists of (the namespace, its imports, and the base namespace behind them, whose enclosure is the global environment); the right column is search(), where library() adds package:shelf in second place. loadNamespace() alone fills only the middle column, and shelf::book reads from it without changing anything on the right.

R Internals describes the same environments: a package pkg defines two environments, namespace:pkg and package:pkg; the first holds the objects defined by the package’s code, the second is populated with the selected symbols (the exports) of the first, and it is package:pkg that is attached. The enclosure of the namespace is an environment holding the explicit imports, the enclosure of that is the base namespace, and the enclosure of the base namespace is the global environment, so the search from a package namespace goes through the explicit and implicit imports to the standard search path. Writing R Extensions states the consequence for package authors: R searches the package namespace first, then the imports, then the base namespace and then the normal search path, so the base namespace comes before the search path rather than at its end, and code in the package can only depend on what is in its own namespace and its imports being visible. That is why a user’s own sum or an attached package’s filter cannot break the functions of a package: they live on the search path, which a package function reaches last.

Source: R Internals: Namespaces

The first script makes the difference visible with shelf, which is installed in the library of the session but not loaded: it loads the namespace, reads an export with ::, attaches the package, detaches it, and unloads it. After each step it asks the questions that the diagram answers.

Source: R documentation: loadNamespace, attachNamespace, requireNamespace, unloadNamespace

The help page of loadNamespace() says the same in its own words: it loads the namespace and registers it in an internal database, a request to load a namespace that is already loaded has no effect (and, since R 4.6.0, arguments that are ignored for that reason are noted), loadNamespace() does not attach the namespace it loads, and attachNamespace() attaches a frame that holds the exported values of the namespace to the search path and then runs .onAttach() (almost always called through library()). isNamespaceLoaded(name) is name %in% loadedNamespaces() but faster. Because exists("normalise_isbn") is FALSE before library(shelf) and TRUE after, the question "is the function available" depends on the attach state; the question "can code in a package that imports shelf use it" does not.

Each loaded package has a namespace environment that can be inspected like any environment. The next script walks the enclosure chain of a package function and asks about the exports and the imports. The chain printed by the first loop is the middle column of the figure: the namespace, imports:shelf, the base namespace (named base), the global environment (R_GlobalEnv) and then the attached packages in search path order.

Source: R documentation: getNamespace, getNamespaceExports, getNamespaceImports and related functions

environment(fn) is the environment where a function was defined, which for a package function is the namespace; topenv() finds the nearest top-level environment (a namespace, an attached package environment or the global environment) from any environment, and is what code that must locate "its package" uses. getNamespace() and asNamespace() return the same environment, and asNamespace() also accepts a namespace object and, like ::, loads the namespace if it is not loaded (its documentation). The imports environment is empty for shelf, which imports nothing; for a package whose NAMESPACE says importFrom(stats, sd) it holds sd, and getNamespaceImports() lists the imports by package. The namespace has more objects than the exports: the internals, the hooks, and the dot-objects R maintains (.__NAMESPACE__. holds the package name, version, path and the lists of exports and imports; .__S3MethodsTable__. the registered methods). A namespace is sealed once it is loaded: imports and exports cannot be changed and neither can the internal bindings, Writing R Extensions says, which is what allows tools to find the definition that corresponds to a global variable reference in a function body and is why patching a package from the outside needs assignInNamespace() (a last resort, for fixing a function in a running session) rather than an assignment.

The S3 methods of a package are registered in a table by the S3method() directives of NAMESPACE, so a method such as print.book is not exported and not visible by name (exists("print.book") is FALSE), but print() finds it, and getS3method("print", "book") retrieves it; the script in the next section shows both, together with the ::: operator.

pkg::name returns the value of the exported object name of the namespace of pkg; pkg:::name returns the value of the internal object. Both load the namespace if it is not loaded and neither attaches the package, so a script can use one function of a package without changing the search path. The help page is exact about what :: does not do: pkg::name does not access the environment package:pkg (which does not exist until the namespace is attached), and it does reach data sets made available by lazy loading, so shelf::books works without library(shelf). Since it goes to the namespace, it ignores masking: stats::sd is stats::sd whatever sd means in the workspace. The package and the name may be symbols or literal strings; a package name held in a variable needs getExportedValue() (or loadNamespace() and get()), as the script below shows.

The two kinds of failure have different messages: a missing package gives the "there is no package called" error of library(), a name that is not exported gives "'name' is not an exported object from 'namespace:pkg'" and, for the triple colon, "object 'name' not found". The :: is a little less efficient than an import, Writing R Extensions notes, and loses the advantage of recording all dependencies in NAMESPACE (they must still be in DESCRIPTION), but for a package that needs two functions of another package it is perfectly reasonable, and for scripts it is the clearest way to say where a function comes from. The packages in Imports do not need a library(): pkg::f() is enough, and importFrom(pkg, f) in NAMESPACE is the form for heavy use.

::: is another matter. The note on its help page calls it typically a design mistake to use ::: in code, because the object has probably been kept internal for a good reason, and suggests contacting the package maintainer unless the intention is mere inspection. The script shows what it can do (call an internal helper of shelf, read its internal data), the two ways to reach the same object without the operator, getFromNamespace() and get() on the namespace, and where the S3 methods of a package are (registered, not exported).

The alternatives do not make the dependency any safer: an internal function can change or disappear in any release, with no deprecation. R CMD check knows this, and its check "dependencies in R code" reports both a package used with :: that is not declared in DESCRIPTION and a ::: call. To see the real text, the example adds a file R/peek.R to a copy of the shelf package: one function that uses utils:::format.object_size(), tools::file_ext() and dplyr::bind_rows(), with no dplyr entry in DESCRIPTION:

Source: Writing R Extensions: Specifying imports and exports

The package was built and checked like this (the header of the check output, which names the platform and the compiler, is trimmed, and only the relevant check and the final status are shown):

Source: Writing R Extensions: Checking packages

The two lines are different in kind. The first is the missing declaration: dplyr::bind_rows() needs dplyr in Imports (or Suggests when the use is conditional), and a package that skips it fails on a machine where dplyr is not installed. tools::file_ext() is not reported because tools is a base package. The second is the ::: call, with the pointer to the help page; for CRAN submissions this is a reason for a request to change the code (the Publishing to CRAN page covers the policy).

search() returns the environments that R looks through when it evaluates a name from the workspace, starting with .GlobalEnv and ending with package:base; searchpaths() adds the folder from which each package was loaded. A new session has the default packages in the reverse order of attaching, then Autoloads (the environment of objects set up with autoload()) and package:base (the startup page has the default list and how to change it). library() attaches at position 2, just after the workspace, so the most recently attached package masks the older ones and the workspace masks all of them; the argument pos of library() (a number or the name of an entry of the search path) chooses another position, and the help page of library suggests pos = "package:base" for the case where a package should mask as little as possible. R Internals states the shape of the path: the global environment, then the environments that have been attached, and finally the base environment, with no way to attach before the workspace or after the base environment.

Source: R documentation: search

A package environment is locked after it is attached: the bindings cannot be changed with assign() (the last lines of the script), which is why the way to change a function from a package is to write one with the same name in the workspace (masking it, visibly), not to modify the package environment. find() (in the utils package) answers "where is this name": every attached environment that has it, first match first. attach() of a data frame puts a copy of its columns at position 2 as well, and is best avoided, as the attach help page says; the Sessions, Workspaces and Startup page and Data Frames have the alternatives (with(), data = arguments). The workspace is first, so an object in it masks every attached package, which is why a workspace restored from an old .RData file can change what a script does.

When a package is attached and exports a name that is already on the search path in an environment later than position 2, the new one masks the old one, and library() says so. The standard example is the two packages that both define select(): MASS (a recommended package) and dplyr. The script attaches them in the two orders and prints the real messages. Note that the same message also reports that dplyr masks functions of stats and base; those masks are intentional (dplyr’s filter() and lag() are not the stats ones, and its set functions work on data frames), and package code is not affected, because the namespace of a package reaches the base namespace and its imports before the search path. conflicts() lists the names that exist in more than one place of the search path, conflicts(detail = TRUE) the masked and masking names by search path entry, and find() shows the places of one name.

Source: R documentation: conflicts

The answer to a conflict is a decision about who should win, and R offers several ways to state it, from the lightest to the heaviest:

Source: R documentation: library (conflicts)

The arguments exclude, include.only and mask.ok, the function conflictRules() and the option conflicts.policy belong to one facility, whose introduction is in the R 3.6.0 NEWS: library() and require() allow more control over the handling of search path conflicts when packages are attached, and the policy is controlled by the new conflicts.policy option. The next script shows each: include.only and exclude (and the messages they leave), the unchanged report when mask.ok is used without a strict policy, warn.conflicts = FALSE, the strict policy with its error text, and the strict policy made to pass by listing every conflicting name, once in the call and once as a rule.

Source: R documentation: library and conflictRules

The strict policy is most useful as a smoke test in a script that attaches many packages: it turns the polite message that everybody ignores into an error with the full list of the conflicting names, and mask.ok is the place to say, once, which ones were reviewed. exclude and include.only cannot be used together in one call, and attach.required is missing(include.only) by default, so with include.only the packages in Depends are not attached automatically.

use() is a wrapper around library() for scripts that want to say exactly what they import, and that should read like the NAMESPACE of a package. use(package, include.only) loads the namespace and attaches only the named exports (all of them when include.only is missing), and always uses attach.required = FALSE, so that the packages listed in Depends are not attached. The help page says why: it gives a script full control over what is found on the search path, and such a script can be turned into package code by replacing the calls to use() with the corresponding importFrom directives in NAMESPACE. It returns a logical invisibly, and the help page calls the functionality still experimental, with interfaces that may change in future versions, so it is a feature to try in scripts, not yet one to build a framework on. The function is documented in the R 4.5.0 NEWS as a new function for using packages in scripts with full control over what gets added to the search path, and the NEWS entry adds that it was actually already available since R 4.4.0; code for R 4.3 or older must use library(pkg, include.only = ), which use() wraps. It has no exclude argument.

The script uses two tiny packages in a scratch library, shelfplus with Depends: shelfcore, to show the one difference that matters: library(shelfplus) also attaches shelfcore, use("shelfplus") does not.

Source: R documentation: use

detach("package:pkg") removes the package environment from the search path and leaves the namespace loaded; unloadNamespace("pkg") detaches the package if it is attached and then removes the namespace, running .onDetach() or .Last.lib() and then .onUnload(); detach("package:pkg", unload = TRUE) is the combination, and it only attempts the unloading. All three can fail or leave things behind, which is why the manuals repeat a warning. The detach() help page says that detaching does not unload the namespace by default and may not even with unload = TRUE; that it does not in general unload dynamically loaded compiled code (DLLs); that registered S3 methods are not removed, because they are not tagged with their source package; that library() on a package whose namespace is loaded attaches the exports of the already loaded namespace, so detaching and re-attaching may not refresh some or all components of the package; and that the most reliable way to completely detach a package is to restart R. It adds that unloading some namespaces has side effects (unloading grid closes all graphics devices, and tcltk may not be reloadable). A namespace that another loaded namespace imports cannot be unloaded at all: unloadNamespace() signals an error and detach(unload = TRUE) turns it into a warning. The script shows both, using knitr and rmarkdown (which imports knitr), and the option that .onLoad() set surviving the unloading of shelf.

Source: R documentation: detach

The consequences for daily work: to reload a package after changing it, restart R (or start a fresh session from a script runner); devtools::load_all() and pkgload do a development-time reload by sourcing the package in place and are the right tools while writing one (the Creating Packages page); and detach(unload = TRUE) in a script is a code smell, because whatever it was meant to fix, a restart fixes reliably.

The packages attached at startup are getOption("defaultPackages"): datasets, utils, grDevices, graphics, stats and methods, plus base. The option is initially set from the environment variable R_DEFAULT_PACKAGES (a comma-separated list, or NULL for none but base); it can be changed in .Rprofile, but the options help page notes that excluding methods there does not work, because the value is screened for methods before the profile is read. Reducing the set is a way of making Rscript start faster (R-admin says that not using methods can reduce the startup time by a factor of up to two) and of finding hidden dependencies on attached packages. Rscript has its own controls: the option --default-packages=LIST, and the environment variable R_SCRIPT_DEFAULT_PACKAGES, which takes precedence over R_DEFAULT_PACKAGES. Before R 3.5.0 Rscript did not attach methods; since R 3.5.0 it attaches the same default packages as R (the NEWS says that the old behaviour can be restored for the time being with R_SCRIPT_LEGACY=yes), which is what makes a script written interactively run the same under Rscript. These runs were done in a shell; the output is shown under each command:

Source: R Installation and Administration: Default packages

The --default-packages run shows the packages in the order they were loaded reversed on the path (utils first, so stats ends up in front); the R_SCRIPT_LEGACY=yes run shows the old Rscript without methods; and the last two show why R_DEFAULT_PACKAGES=NULL is a good test: sd() is in stats, which is not attached, so the unqualified call fails with the same "could not find function" error that a script gets when it forgets library(), and stats::sd() works. A script that qualifies everything that is not in base with pkg:: (or states its library() calls) runs the same however it is started. The non-zero exit status is the point of the echo line: Rscript returns 1 after an uncaught error, which the Scripts and the Command Line page uses.

A script that needs packages should state that at the top, as a list of library() calls (one per line, the same order every time, because the order decides masking) or, when it uses a package once, as pkg:: calls, and it should check, not install: installing packages as a side effect of running a script changes the machine, needs network and permissions, and makes a result depend on the day it ran. The next script is the usual guard. requireNamespace(quietly = TRUE) is the cheap test; system.file(package = ) and find.package(quiet = TRUE) test for a package without loading anything. For a project, the set of packages and their versions is a property of the project and belongs in a lockfile, which is what the renv page does; for a package that other people install, it belongs in DESCRIPTION.

Source: R documentation: requireNamespace

Every text in the table was produced by the scripts above (or by the shell lines); quotation marks are the typographic ones that R prints in a UTF-8 locale.

Source: R documentation: library

Two further messages that no script here can produce on purpose deserve a mention. When an installed package was built under a later R version than the running one, library() warns, and the repair is to update the package or the R; and a package that was installed for a different R minor version and has compiled code may fail to load with a message from the operating system’s loader, which is why update.packages(checkBuilt = TRUE) follows an upgrade of R. Neither text was captured here, so neither is quoted.

The entries come from the NEWS files of the releases (R NEWS; the entries up to R 3.6.1 are in R NEWS: Changes in R 3.x). The searches for R_DEFAULT_PACKAGES and defaultPackages in the R 4.0.0 to 4.6.1 NEWS found no entry: the default packages and the variable that sets them were not changed in those releases.

Source: R NEWS: Changes in R 3.5.0 to 4.6.1

The R-devel entries are from the R-devel NEWS and may change before 4.7.0 is released.

Source: R FAQ 7.29: What is the difference between package and library?