Open jennybc opened 1 year ago
Hi @jennybc, I think, this has become an issue for me in the following context:
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. 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 defaultbuild_readme()
calls install(..., dependencies = FALSE)
instead of keeping install()
in eager modebuild_readme()
let's me pass dependencies = FALSE
to the install()
commandI'll find a workaround in the meantime, just wanted to share this user experience in this context. Thanks, skr
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.
+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.
It feels to me like it's time to switch to pak here.
This requires more analysis, but my current thinking is that
install()
should not, by default, be so eager to update packages.