Skip to content

A package reference (ref) specifies a location from which an R package can be obtained from. The full syntax of a reference is type::ref, but type can be often omitted, the common ref types have shortcuts.



The currently supported reference types are:

  • cran: a CRAN package.

  • bioc: A Bioconductor package.

  • standard: a package from CRAN or Bioconductor.

  • github: A package from GitHub.

  • local: A local package file or directory.

  • url: An URL to a package archive.

  • installed An installed package.

  • deps The dependencies of a local package file or directory.

  • any A special reference type that accepts a package from any source. See below.

If a ref does not explicitly specify a type, then the following rules are applied:

  • if the ref is a valid standard ref type (without the standard:: prefix), then standard is used;

  • if the ref is a valid github ref type (without the github:: prefix), then github is used;

  • if the ref is a GitHub URL, then github is used;

  • otherwise an error is thrown.


Package refs may have optional parameters, added after a question mark. Different parameters are separated by an ampersand (&) character. Parameters might be binary, or have a string value, assigned with an equal sign (=). If no value is assigned, then we assume the true value. For example these two package refs are the same:


Some parameters given in a special form allow configuring downstream dependencies:


can be given at the command line and refers to a (potential) downstream package.

Currently supported parameters:

  • ignore is a binary parameter. If specified the package is ignored. This usually makes sense in the packagename=?ignore form, to ignore a downstream soft dependency. If all versions of a hard dependency are ignored that will lead to a solution error.

  • ignore-before-r is a version number parameter. The package will be ignored on R versions that are older than the specified one. E.g. Matrix=?ignore-before-r=4.1.2 will ignore the Matrix package on R versions that are older than 4.1.2. This parameter really only makes sense in the packgename=?ignore form.

  • source is a binary parameter. If specified, then a source R package is requested from a CRAN-like repository. For package installations source always triggers a re-install. In other words, source implies the reinstall parameter. This parameter is supported for bioc::, cran:: and standard:: remote types, and it is ignore for others.

  • reinstall requests a re-install for package installations. It is supported by the bioc::, cran::, github::, local::, standard::, and url:: remote types.

  • nocache will ignore the package cache. It will always download the package file, and it will not add the downloaded (and built) file to the package cache. It is supported by the bioc::, cran::, github::, standard:: and url:: remote types.

CRAN packages:

A package from CRAN. Full syntax:

[cran::]<package>[@[>=]<version> | current | last]

  • <package> is a valid package name.

  • <version> is a version or a version requirement.



Note: pkgdepends currently parses the version specification part (everything after @), but does not use it.

Bioconductor packages:

A package from Bioconductor. The syntax is the same as for CRAN packages, except of the prefix of course:

[bioc::]<package>[@[>=]<version> | current | last]

Standard packages:

These are packages either from CRAN or Bioconductor, the full syntax is the same as for CRAN packages, except for the prefix:

[standard::]<package>[@[>=]<version> | current | last]

GitHub packages:

Packages from a GitHub repository. Full syntax:


  • <package> is the name of the package. If this is missing, then the name of the repository is used.

  • <username> is a GitHub username or organization name.

  • <repository> is the name of the repository.

  • <subdir> optional subdirectory, if the package is within a subdirectory in the repository.

  • <detail> specifies a certain version of the package, see below.

<detail> may specify:

  • a git branch, tag or (prefix of) a commit hash: @<commitish>;

  • a pull request: #<pull-request>; or

  • the latest release: @*release.

If <detail> is missing, then the latest commit of the default branch is used.



For convenience GitHub HTTP URLs can also be used to specify a package from GitHub. Examples:
# A branch:
# A tag:
# A commit:
# A pull request:
# A release:

A GitHub remote string can also be used instead of an URL, for example:

Local packages:

A path that refers to a package file built with R CMD build, or a directory that contains a package. Full syntax:


For brevity, you can omit the local:: prefix, if you specify an absolute path, a path from the user’s home directory, starting with ~, or a relative path starting with ./ or .\.

A single dot (".") is considered to be a local package in the current working directory.




You can use url:: to refer to URLs that hold R package archives (i.e. properly built with R CMD build), or compressed directories of package trees (i.e. not built with R CMD build). pkgdepends will figure out if it needs to run R CMD build on the package first.

This remote type supports .tar.gz and .zip files.

Note that URLs are not ideal remote types, because pkgdepends needs to download the package file to resolve its dependencies. When this happens, it puts the package file in the cache, so no further downloads are needed when installing the package later.



Installed packages:

This is usually used internally, but can also be used directly. Full syntax:


  • <path> is the library the package is installed to.

  • <package> is the package name.



Package dependencies:

Usually used internally, it specifies the dependencies of a local package. It can be used to download or install the dependencies of a package, without downloading or installing the package itself. Full syntax:




any:: packages

Sometimes you need to install additional packages, but you don’t mind where they are installed from. Here is an example. You want to install cli from GitHub, from r-lib/cli. You also want to install glue, and you don’t mind which version of glue is installed, as long as it is compatible with the requested cli version. If cli specifies the development version of glue, then that is fine. If cli is fine with the CRAN version of glue, that’s OK, too. If a future version of cli does not depend on glue, you still want glue installed, from CRAN. The any:: reference type does exactly this.

In our example you might write

pak::pkg_install(c("glue", "r-lib/cli"))

first, but this will fail if rlib/cli requests (say) tidyverse/glue, because in pkg_install() "glue" is interpreted as "standard::glue", creating a conflict with tidyverse/glue. On the other hand

pak::pkg_install(c("any::glue", "r-lib/cli"))

works, independently of which glue version is requested by cli.