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
add 'remotes.upgrade' option for upgrade toggle #240
add 'remotes.upgrade' option for upgrade toggle #240
Conversation
Thanks! Sounds good. However, we already have some environment variables, see https://github.com/r-lib/remotes#environment-variables Environment variables are better in some ways, e.g. subprocesses inherit them, and you can set them globally for all R sessions. Do you have a particular reason to have an option instead of an env var? |
Using an R option just seemed the most natural mechanism when I first thought about it, but I'd be entirely open to using environment variables (especially if we want / need to think about subprocesses). Would using e.g. |
Yeah, I like that. Can you please also add it to the list of env vars in the README? Thanks! |
240a495
to
3d7a799
Compare
R/deps.R
Outdated
@@ -529,6 +529,14 @@ remote_deps <- function(pkg, ...) { | |||
res | |||
} | |||
|
|||
upgrade_default <- function() { | |||
|
|||
env <- Sys.getenv("R_REMOTES_UPGRADE", unset = NA) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't this whole function just be
env <- Sys.getenv("R_REMOTES_UPGRADE", unset = NA) | |
Sys.getenv("R_REMOTES_UPGRADE", "ask") |
My main concern with this is you lose the auto-documenting behavior of An alternative would be to keep the arguments the same and add logic to We are already changing the default for non-interactive sessions, so maybe just adding it there is ok. |
We could have |
3d7a799
to
70959f2
Compare
I've updated the PR with the new |
This LGTM |
Thanks! |
This allows users to specify a default upgrade preference (for those of us who might prefer automatically updating dependent packages when installing the development version of a package).