Skip to content

install() can cause unnecessary re-installation of dependencies #2691

Closed

Description

@jennybc

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

devtools/R/install.R

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

devtools/R/install.R

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

  1. jennybc commented on Apr 23, 2026

    @jennybc
    MemberAuthor

    No one ever opened an issue but here's some discussion:
    https://c.im/@pglpm/116419927849177428

    Key sentiment:

    I see now that it insists on installing package dependencies (in the user's libPath), even though all dependencies are already available for all users from the system-wide libPath. This didn't happen some versions ago. I'm on Linux.

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions