pak_package_sources: Package sources

Description

Package sources

Arguments

Standard packages

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:

## CRAN package
pkg_install("glue")
## BioC package
pkg_install("limma")

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

[standard::]<package>

If you know the exact source of the package, you can also write

cran::<package>
bioc::<package>

GitHub packages

pak can install packages from GitHub repositories. Any package that is specified in the user/repo notation is taken to be a GitHub package. For example:

## 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.
The @*release string can be used to install the latest release.

Local package trees

pak can install packages from package trees. You can either use the local_install() function for this, or specify the local:: package source. E.g. these are equivalent:

local_install("/path/to/my/package")
pkg_install("local::/path/to/my/package")

The local:: form is handy if you want to mix it with other package specifications, e.g. to install a local package, and another standard package:

pkg_install(c("local://path/to/my/package", "testthat"))

The <code>Remotes</code> field

You can mark any regular dependency defined in the Depends, Imports, Suggests or 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:

Remotes: <pkg-source-1>, <pkg-source-2>, [ ... ]

Note that you will still need add the package to one of the regular dependency fields, i.e. Imports, Suggests, etc. Here is a concrete example that specifies the r-lib/glue package:

Imports: glue
Remotes: `r-lib/glue,
  r-lib/httr@v0.4,
  klutometis/roxygen#142,
  r-lib/testthat@c67018fa4970

The CRAN and Bioconductor repositories do not support the Remotes field, so you need to remove this field, before submitting your package to either of them.

The package dependency solver

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"))
Error: Cannot install packages:
  * Cannot install `r-lib/pkgcache@conflict`.
    - Cannot install dependency r-lib/cli@master
  * Cannot install `r-lib/cli@master`.
- Conflicts r-lib/cli@message

r-lib/pkgcache@conflict depends on the master branch of r-lib/cli, 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 pkgA and user/pkgB, the latter being a package from GitHub (see below), and that pkgA also depends on pkgB. Now pak must install pkgB and user/pkgB. In this case pak interprets pkgB as a package from any package source, instead of a standard package, so installing user/pkgB satisfies both requirements.

Note that that cran::pkgB and 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 package library.