Skip to contents

Create installation proposal using various dependency strategies

Source: R/deps_installation_proposal.R
deps_installation_proposal.Rd

These functionalities would read local package DESCRIPTION file, derive dependencies from "Config/Needs/verdepcheck" and create an installation proposal using various strategies for package versions as described below.

Usage

new_max_deps_installation_proposal(
  path,
  extra_deps = character(0L),
  config = list()
)

new_release_deps_installation_proposal(
  path,
  extra_deps = character(0L),
  config = list()
)

new_min_cohort_deps_installation_proposal(
  path,
  extra_deps = character(0L),
  config = list()
)

new_min_isolated_deps_installation_proposal(
  path,
  extra_deps = character(0L),
  config = list()
)

Arguments

path

(string) path to the package sources

extra_deps

(character(1)) Extra dependencies specified similarly as in the DESCRIPTION file, i.e. "<package name> (<operator> <version>)" where both <operator> and <version> are optional. Multiple entries are possible separated by ";".

config

(list) configuration options. See pkgdepends::pkg_config for details. "dependencies" and "library" elements are overwritten by package level defaults.

Value

pkg_installation_plan object

strategies

Currently implemented strategies:

  • max - use the greatest version of dependent packages. Please note that using development version is not guaranteed to be stable. See get_ref_max for details.

  • release - use the released version of dependent packages. It will try use CRAN if possible else if GitHub release is available then use it else fail. See get_ref_release for details.

  • min_cohort - find maximum date of directly dependent packages release dates and use that as PPM snapshot date for dependency resolve.

  • min_isolated - for each direct dependency: find its release date and use it as PPM snapshot for resolving itself. Next, combine all the individual resolutions and resolve it altogether again.

Both "min" strategies relies on PPM snapshot in order to limit the versions of indirect dependencies so that dependency resolution ends with a package released no earlier than any of its dependency. However, that's not always true for min_isolated strategy - done on purpose.

Please note that only min_cohort and min_isolated strategies are "stable". The rest are basing on dynamic references therefore it results might be different without changes in tested package. The most straightforward example is max strategy in which the environment will be different after any push of any of the dependencies.

configuration

verdepcheck will look into "Config/Needs/verdepcheck" field of the DESCRIPTION file for dependent packages references. See pkgdepends::pkg_refs for details and this package DESCRIPTION file for an example. Please note that some features are enabled only for package references from GitHub. If you specify additional details (i.e. tag, commit, PR or @*release) in the reference then it wouldn't be changed. Therefore, in order to make full use of various strategies, it is recommended to specify general reference in form of [<package>=][github::]<username>/<repository>[/<subdir>] - i.e. without [<detail>] part. Please see also pkgdepends::pkg_config and pak::pak-config for other configuration possibilities.

See also

pkgdepends::pkg_installation_proposal

Examples

if (FALSE) { # Sys.getenv("R_USER_CACHE_DIR", "") != ""
x <- new_max_deps_installation_proposal(".")
x$solve()
x$get_solution()
}
if (FALSE) { # Sys.getenv("R_USER_CACHE_DIR", "") != ""
x <- new_release_deps_installation_proposal(".")
x$solve()
x$get_solution()
}
if (FALSE) { # Sys.getenv("R_USER_CACHE_DIR", "") != ""
x <- new_min_cohort_deps_installation_proposal(".")
solve_ip(x)
x$get_solution()
}
if (FALSE) { # Sys.getenv("R_USER_CACHE_DIR", "") != ""
x <- new_min_isolated_deps_installation_proposal(".")
solve_ip(x)
x$get_solution()
}