Repository navigation
install() can cause unnecessary re-installation of dependencies #2691
Description
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
Lines 89 to 93 in 51f04a5
| 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
Lines 97 to 101 in 5387045
| 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.
Activity
jennybc commentedon Apr 23, 2026
No one ever opened an issue but here's some discussion:
https://c.im/@pglpm/116419927849177428
Key sentiment:
A related commit elsewhere:
jdblischak/gs-integration-tests@3427915
I think this mostly affects ... linux users? In my setup, the first lib path will always be my user library, so installing the in-development package there is good. And resolving package dependencies with respect to that library is also good. So I don't see this tendency towards re-installation. But clearly there are linux setups that tickle it.