Why is `install()` so keen to update packages?

[jennybc]

This requires more analysis, but my current thinking is that install() should not, by default, be so eager to update packages.

[skr5k]

Hi @jennybc,
I think, this has become an issue for me in the following context:

• I maintain a few proprietary R packages that have interdependencies and are only available on a local git server
• When trying to build a README.md file, I use devtools::build_readme() which calls devtools::build_rmd() which somewhere in the middle has the line local_install(pkg, quiet = TRUE) which then tries to locally install my package with its problematic eagerness to update the local dependencies.
• The update, however, fails, because the install() function doesnt have the login credentials to git (and in fact I can neither pass on git credentials nor a dependencies = FALSE option down the chain to the install command)

Thus, I can personally think of three ways to deals with my problem:

• install() doesn't check for updates by default
• build_readme() calls install(..., dependencies = FALSE) instead of keeping install() in eager mode
• build_readme() let's me pass dependencies = FALSE to the install() command

I'll find a workaround in the meantime, just wanted to share this user experience in this context.
Thanks,
skr

[jennybc]

I view this more evidence that it will be good to start using pak inside devtools. In which case install() would probably wrap pak::local_install(), whose upgrade argument has some 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.

When upgrade = TRUE, pak will ensure that you have the latest version(s) of pkg and all their dependencies.

Compare this to the upgrade argument of remotes::install_deps(), which is currently used inside `devtools::install():

Should package dependencies be upgraded? One of "default", "ask", "always", or "never". "default" respects the value of the R_REMOTES_UPGRADE environment variable if set, and falls back to "ask" if unset. "ask" prompts the user for which out of date packages to upgrade. For non-interactive sessions "ask" is equivalent to "always". TRUE and FALSE are also accepted and correspond to "always" and "never" respectively.

[infotroph]

+1 to rethinking this, and in particular I wonder how essential it is to check for available updates even when upgrade = FALSE.

In PEcAn Project we install and test dozens of packages in a single CI run that tries to match the user-facing installation experience and therefore calls install separately for each package. Many of our packages share dependencies that we install from GitHub at the start of the run. But each call to installs insists on checking for updates to each dependency again, and we've run into cases where just those update checks were enough to exceed the request limit of our GitHub token... even though we know we brought all the remotes up to date at the start of the run.

It's very possible our CI use case is better suited to a non-devtools installation method such as remotes::install_local, but we do like using devtools in our user-facing installation and keeping the CI run as equivalent to that as possible.

[hadley]

It feels to me like it's time to switch to pak here.