Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is install() so keen to update packages? #2486

Open
jennybc opened this issue Nov 17, 2022 · 4 comments
Open

Why is install() so keen to update packages? #2486

jennybc opened this issue Nov 17, 2022 · 4 comments
Labels

Comments

@jennybc
Copy link
Member

jennybc commented Nov 17, 2022

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

@skr5k
Copy link

skr5k commented May 4, 2023

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
Copy link
Member Author

jennybc commented Nov 2, 2023

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
Copy link
Contributor

+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
Copy link
Member

hadley commented Jul 23, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants