Closed slodge closed 3 years ago
Can you elaborate a bit more on what's going on here? Setting RENV_R_INITIALIZING
would indeed be a workaround, since that would trick renv
into thinking it's already been initialized (and so should do nothing).
This might be addressed with https://github.com/rstudio/rsconnect/issues/439, which asks that rsconnect ignore renv initialization code in an .Rprofile.
A section of our rmarkdown rendering when it picked up the .Rprofile
* Installing renv 0.12.0 ... Done!
2020/10/16 11:13:43.098055365
Successfully installed and loaded renv 0.12.0.
2020/10/16 11:13:43.124827936
Error: failed to create directory at path '/home/rstudio-connect/.local/share/renv'
2020/10/16 11:13:43.125110640
In addition: Warning message:
2020/10/16 11:13:43.125126191
In dir.create(rownames(info), recursive = TRUE) :
2020/10/16 11:13:43.125266000
cannot create dir '/home/rstudio-connect/.local', reason 'Permission denied'
2020/10/16 11:13:43.135382986
Traceback (most recent calls last):
2020/10/16 11:13:43.135459689
18: source("renv/activate.R")
2020/10/16 11:13:43.135528003
17: withVisible(eval(ei, envir))
2020/10/16 11:13:43.135576705
16: eval(ei, envir)
2020/10/16 11:13:43.135623903
15: eval(ei, envir)
I've not looked at this fully yet - so feel free to hold off - it could be something we're doing wrong!
@slodge overall we don't recommend deploying .Rprofiles to Connect. One simple workaround would be to remove the .Rprofile from the deployment bundle; unless you have a very good reason for including it?
The .Rprofile wasn't listed in the manifest json. It was in the git repo. The "deploy from git" ignores the manifest and pulls all files in the manifest folder (which we kind of like).
We're ecouraging users to deploy their apps to rs connect and we're encouraging them to use renv. This was just the first time the two clashed.
We've already repaired this instance by moving the app out of the root folder - but I'm now looking to work out how to avoid this or other similar problems in the future. Just trying to make the deployment process as easy as possible for our users while also ensuring reproducibility across desktops and servers.
I guess this might not be a renv issue - might instead be something we need Connect to protect against?
On Fri, 16 Oct 2020, 20:49 Sean Lopp, notifications@github.com wrote:
@slodge https://github.com/slodge overall we don't recommend deploying .Rprofiles to Connect. One simple workaround would be to remove the .Rprofile from the deployment bundle; unless you have a very good reason for including it?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstudio/renv/issues/561#issuecomment-710510891, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECJHT5VM4V6WXP54EDUADSLCPUJANCNFSM4STG46UA .
IIUC this was resolved via https://github.com/rstudio/rsconnect/pull/462.
Is there any way to disable renv at a machine level?
We've got a user who's just deployed a root level manifest.json to RStudio Connect.
This causes our Connect instance to run renv.... which goes horribly wrong.
I'm wondering about setting a value for RENV_R_INITIALIZING in RENVIRON to stop Renv starting. But is there any other better way?