pak can install packages from various package sources. By default, a package name without the specification of its source, refers to a CRAN or Bioconductor package. pak calls these standard packages. For example:
When considering a standard package, the calling version of R is used to determine the available source and binary packages on CRAN and the Bioconductor repositories.
The full specification of standard packages is simply
If you know the exact source of the package, you can also write
pak can install packages from GitHub repositories. Any package that
is specified in the
user/repo notation is taken to be a GitHub package.
## Package from GitHub pkg_install("r-lib/glue")
The full specification of GitHub packages is
<package>=][github::]<username>/<repo>[/<subdir>] [@<committish> | #<pull> | @[*]release] [
<package>is the name of the package. If this is missing, the name of the package must match the name of the repository.
<username>: GitHub user or organization name.
<repo>: repository name.
<subdir>: If the R package is in a subdirectory within the repository.
<commitish>: A branch name, git tag or SHA hash, to specify the branch, tag or commit to download or install.
<pull>: Pull request number, to install the branch that corresponds to a pull request.
@*releasestring can be used to install the latest release.
pak can install packages from package trees. You can either use the
local_install() function for this, or specify the
source. E.g. these are equivalent:
local:: form is handy if you want to mix it with other package
specifications, e.g. to install a local package, and another standard
You can mark any regular dependency defined in the
Enhances fields as being installed from a remote
location by adding the remote location to
Remotes in your
DESCRIPTION file. This will cause pak to download and install them
from the specified location, instead of CRAN.
The remote dependencies specified in
Remotes is a comma separated
list of package sources:
: <pkg-source-1>, <pkg-source-2>, [ ... ]Remotes
Note that you will still need add the package to one of the regular
dependency fields, i.e.
Suggests, etc. Here is a concrete
example that specifies the
: glue Imports: r-lib/glue, Remotesfirstname.lastname@example.org, r/roxygen#142, klutometis-lib/testthat@c67018fa4970 r
The CRAN and Bioconductor repositories do not support the
field, so you need to remove this field, before submitting your package
to either of them.
pak contains a package dependency solver, that makes sure that the package source and version requirements of all packages are satisfied, before starting an installation. For CRAN and BioC packages this is usually automatic, because these repositories are generally in a consistent state. If packages depend on other other package sources, however, this is not the case.
Here is an example of a conflict detected:
> pak::pkg_install(c("r-lib/pkgcache@conflict", "r-lib/cli@message")) : Cannot install packages: Error* Cannot install `r-lib/pkgcache@conflict`. - Cannot install dependency r-lib/cli@main * Cannot install `r-lib/cli@main`. - Conflicts r-lib/cli@message
r-lib/pkgcache@conflict depends on the main branch of
whereas, we explicitly requested the
message branch. Since it cannot
install both versions into a single library, pak quits.
When pak considers a package for installation, and the package is given with its name only, (e.g. as a dependency of another package), then the package may have any package source. This is necessary, because one R package library may contain only at most one version of a package with a given name.
pak's behavior is best explained via an example.
Assume that you are installing a local package (see below), e.g.
local::., and the local package depends on
the latter being a package from GitHub (see below), and that
also depends on
pkgB. Now pak must install
In this case pak interprets
pkgB as a package from any package source,
instead of a standard package, so installing
user/pkgB satisfies both
Note that that
user/pkgB requirements result a
conflict that pak cannot resolve. This is because the first one must
be a CRAN package, and the second one must be a GitHub package, and
two different packages with the same cannot be installed into an R