-
Notifications
You must be signed in to change notification settings - Fork 155
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
renv
does not respect user repository configuration
#1975
Comments
I wonder if this is possibly an RStudio issue -- do you see the same behavior if you use |
Thanks for your input!!! It seems you are right about Rstudio being the culprit for ignoring the global However, also when running directly in the Rgui for windows, the time it takes to grab a package is controlled by the Here are some quick tests from Rgui on Windows: # Global options
dir.create("test-renv-1")
setwd("test-renv-1")
renv::status()
#> This project does not appear to be using renv.
#> Use `renv::init()` to initialize the project.
getOption("repos")
#> CRAN
#> "https://my.mirror.com/"
# Create renv-managed project
renv::init(bare = TRUE)
#> - renv activated -- please restart the R session.
### RESTART
setwd("test-renv-1")
source("renv/activate.R")
renv::snapshot()
renv::status()
#> No issues found -- the project is in a consistent state.
getOption("repos")
#> CRAN
#> "https://my.mirror.com/" So far so good. The global options are respected by However, the actual time it takes to get a package can still be controlled by the renv::install("tictoc")
Sys.getenv("RENV_CONFIG_CONNECT_TIMEOUT")
#> [1] "15"
tictoc::tic()
renv::install("digest", prompt = FALSE)
tictoc::toc()
#> 15.74 sec elapsed
Sys.setenv(RENV_CONFIG_CONNECT_TIMEOUT = 25)
tictoc::tic()
renv::install("digest", prompt = FALSE)
#> The following package(s) will be installed:
#> - digest [0.6.37]
#> These packages will be installed into "~/test-renv-1/renv/library/windows/R-4.4/x86_64-w64-mingw32".
#> # Installing packages --------------------------------------------------------
#> - Installing digest ... OK [copied from cache in 0.37s]
#> Successfully installed 1 package in 0.43 seconds.
tictoc::toc()
#> 25.75 sec elapsed
Could this a bug somewhere? Or have I messed up the configurations somewhere 🤔? |
Resolved - not a bug, just poor configuration! 🙈I found the reason that the Tracing the call stack of The ERROR is handled within Now that I know what is going on, it's easy to fix by setting
Summary
|
When in an renv-managed Rstudio project the user repository configuration is ignored.
The server I am working on does not have open internet access. I need to use a specific repos address, we'll call it
"https://my.mirror.com/"
.Global options
I have set the CRAN-mirror to use in the
.Rprofile
.Project options
When moving in to a project, not yet managed by
renv
, the global options are still respected:Initiating
renv
overrides the global optionsWhen initiating
renv
the custom global option is replaced bycloud.r-project.org
:The
repos
argument torenv::init()
also is not respected:Passing in the CRAN mirror using the
repos
argument when initiatingrenv
in the project has no effect:Note
Unsurprisingly, all attempts so far results in a
lock.file
specifying""https://cloud.r-project.org"
as repository to use:Setting the
repos
option after initiatingrenv
also is not respected:Let's try setting the
repos
-option AFTER initiatingrenv
:Now it would appear all configurations are in place. However, I still don't think they are respected by
renv
. Consider the following:Let's see the time it takes to install a package using
renv::install()
:I don't know what happens during the time it takes
renv::install()
to install the package, but the fact that we can control how long it takes by changing theRENV_CONFIG_CONNECT_TIMEOUT
-setting indicates thatrenv
is attempting to connect to somewhere other than the repository specified bygetOption("repos")
/Sys.getenv("RENV_CONFIG_REPOS_OVERRIDE")
.renv::diagnostics()
The text was updated successfully, but these errors were encountered: