This is a very similar problem to one reported re: build_readme() (#2683), but in the install() case we can't "solve" it by just not installing dependencies. This requires an actual feature in pak.
In devtools 2.5.0 we started using pak in places where we previously used remotes. Inside install(), here is the before vs. after for installing the dependencies of the under-development package.
devtools 2.4.6
|
remotes::install_deps(pkg$path, |
|
build = build, build_opts = build_opts, |
|
INSTALL_opts = opts, dependencies = dependencies, quiet = quiet, |
|
force = force, upgrade = upgrade, ... |
|
) |
devtools 2.5.1
|
pak::local_install_deps( |
|
pkg$path, |
|
upgrade = upgrade, |
|
dependencies = dependencies || isTRUE(build_vignettes) |
|
) |
Why the switch? First, we are generally pivoting from remotes to pak. But more importantly, remotes::install_deps() had some annoying behaviour around overeagerly updating dependencies (see #2486). pak::local_install_deps(upgrade = FALSE) has really nice behaviour:
When FALSE, the default, pak does the minimum amount of work to give you the latest version(s) of pkg. It will only upgrade dependent packages if pkg, or one of their dependencies explicitly require a higher version than what you currently have. It will also prefer a binary package over to source package, even it the binary package is older.
The problem is that pak::local_install_deps(lib = .libPaths()[1]) was overly focused on a single library. If it's installing to .libPaths()[1], it was also only consulting .libPaths()[1] during resolution. In practice this can lead to re-installing lots of packages that are already installed at a suitable version in another library on the path.
Full write-up and reprex here: r-lib/pak#865.
pak (pkgdepends, really) already has the main changes necessary to fix this behaviour (r-lib/pkgdepends@634661a). But there are a couple of loose ends still to be tied up: r-lib/pak#864 which unblocks #2690.
This is a very similar problem to one reported re:
build_readme()(#2683), but in theinstall()case we can't "solve" it by just not installing dependencies. This requires an actual feature in pak.In devtools 2.5.0 we started using pak in places where we previously used remotes. Inside
install(), here is the before vs. after for installing the dependencies of the under-development package.devtools 2.4.6
devtools/R/install.R
Lines 89 to 93 in 51f04a5
devtools 2.5.1
devtools/R/install.R
Lines 97 to 101 in 5387045
Why the switch? First, we are generally pivoting from remotes to pak. But more importantly,
remotes::install_deps()had some annoying behaviour around overeagerly updating dependencies (see #2486).pak::local_install_deps(upgrade = FALSE)has really nice behaviour:The problem is that
pak::local_install_deps(lib = .libPaths()[1])was overly focused on a single library. If it's installing to.libPaths()[1], it was also only consulting.libPaths()[1]during resolution. In practice this can lead to re-installing lots of packages that are already installed at a suitable version in another library on the path.Full write-up and reprex here: r-lib/pak#865.
pak (pkgdepends, really) already has the main changes necessary to fix this behaviour (r-lib/pkgdepends@634661a). But there are a couple of loose ends still to be tied up: r-lib/pak#864 which unblocks #2690.