Activation loads grDevices and doesn't inhibit the message

[vspinu]

In my build targets I see an extra Loading required package: grDevices due to loading of renv/activate.R. Placing the activation into suppressPackageStartupMessages block solves the problem but I think this should be taken care on the renv side. In fact I don't think it should load/attach any packages (if this is possible of course).

[kevinushey]

renv itself doesn't load any R packages on startup (besides itself, of course). But grDevices is one of the packages that by default gets loaded in new R sessions; e.g.

$ R --vanilla --slave -e 'loadedNamespaces()'
[1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
[7] "methods"   "base"

(see also ?Startup for details on which packages R loads by default)

Also note (in case this is relevant) that by default renv does source a user profile (e.g. at ~/.Rprofile), so if any packages were being loaded there they would be loaded in renv as well. (For context, the intention is that some users might define utility functions that they use during interactive development that they would want available in their renv projects)

[vspinu]

that by default renv does source a user profile (e.g. at ~/.Rprofile), so if any packages were being loaded there they would be loaded in renv as well.

Arh. This was it. It's surprising as that's not how the default R works.

I actually think this is a bad design as it's undesirable in common colaborative scenarios. It's not only about utilities, but about configuration as well (or different order of package loading as in this example). I want my team to have exactly the same setup. If we decide to source our .Rprofiles it's up to us to do so. Adding source("~/.Rprofile") to local profile is a triviality, but how do I now undo this renv's "user-friendliness"?

Renv can source its own .renvprofile if such an extra flexibility is desired. And it's probably a good idea indeed. Even then I am not sure it should be done by default.

[kevinushey]

This behavior can indeed be toggled -- see within ?config:

#' `user.profile` \tab `logical[1]` \tab `TRUE` \tab
#'   Load the user R profile (typically located at `~/.Rprofile`) when `renv`
#'   is loaded? Consider disabling this if you require extra encapsulation in
#'   your projects; e.g. if your `.Rprofile` attempts to load packages that
#'   you might not install in your projects.
#'   \cr

So the simplest fix would be to set:

RENV_CONFIG_USER_PROFILE=FALSE

within e.g. your project .Renviron, or even your global ~/.Renviron.

We could consider changing this default in the future but thus far I've had more voices in favor rather than against. :-)

This is one of the biggest challenges for me as the developer of renv -- on one hand, I want to prescribe a default workflow that "just works" and feels natural for the average user, without getting in the way too often. On the other hand, I want renv to be configurable enough that it can be useful in separate workflows, or can become part of alternate workflows with separate restrictions, or can accommodate users with different requirements / workflows.

[vspinu]

Thanks! This works for us.

I want to prescribe a default workflow that "just works"

It's easy to become too user-friendly this way. Each such tweak designed to simplify the life of the average Joe creates unnecessary layers of complexity.

Placing source("~/.Rprofile") is a triviality and I think people using renv are not average users anyhow. renv is mostly useful in colaborative environments to share code among developers.

My team moved away from packrat as they couldn't stand the complexities involved. Then we moved to MRAN/checkpoint - simple but not without problems. Now we attempt renv as it seems the way to go, even though it doesn't quite fit our workflow as yet (see my other issues). But even at this stage the system seems quite more complex than we would like. We don't fully understand the magic behind it and the configuration options are already a bit more complex than we would like it to be :)

But ok, one can learn in time any sort of hairy complicated system and be fine with it. This is the danger of complex systems, with time it's no longer complex, but it's still not a good system.

Back to the issue, try placing X11.options(type="cairo") in your user ~/.Rprofile. If renv is not activated it runs as expected. When renv is active I get

error sourcing "~/.Rprofile": could not find function "X11.options" 

I presume that this occurs due to the order in which renv::schims appears in the search path. So things break already with simple .Rprofiles.

Finally, the fact that the R startup is different in such a non-trivial way between when renv is activated or not can be confusing. One would expect that the difference would boil down only to the versions of the libraries used (renv local vs system libraries) but that's not the case. Why bring such surprises for for only what it looks like a marginal benefit to user experience?

[kevinushey]

Placing source("~/.Rprofile") is a triviality and I think people using renv are not average users anyhow.

Well, to be fair, this isn't a great solution -- the project profile is normally also checked in to e.g. git repositories and so is shared with collaborators as part of the project, and so amending the project profile would mean all users would have their user profile sourced. Hence why I wanted this behavior to be configurable on the renv side.

That said, I think your argument is convincing enough to me that we shouldn't source the user profile by default.

[kevinushey]

f450b46

[vspinu]

Thanks!