renv::upgrade() ignores renv.config.autoloader.enabled

[klmr]

The documentation for renv.config.autoloader.enabled says:

[…] renv will not write out the project auto-loader in calls to renv::init().

However, renv::upgrade() does not honour this promise:

mkdir mwe && cd mwe
touch .Rprofile

Rscript -e 'options(renv.config.autoloader.enabled = FALSE); renv::init()'
grep -q renv/activate .Rprofile && echo 'renv touched .Rprofile' || echo 'All is good'

Rscript -e 'options(renv.config.autoloader.enabled = FALSE); renv::upgrade()'
grep -q renv/activate .Rprofile && echo 'renv touched .Rprofile' || echo 'All is good'

This outputs:

All is good
renv touched .Rprofile

In other words: renv::init() behaved correctly, but renv::upgrade() did not.

I suspect that renv::upgrade() launches a subprocess which doesn’t inherit the options of the parent R process. In fact, using the environment variable RENV_CONFIG_AUTOLOADER_ENABLED instead of the option works around this issue.

---

Added context: I am using the ‘rprofile’ package. This package takes care of loading ‘renv’ inside the project .Rprofile file, amongst other things. As a consequence, source("renv/activate.R") should not be added to .Rprofile. ‘rprofile’ suppresses this by setting the aforementioned option. As a consequence of how ‘rprofile’ works, it is installed in the user (or system) package library, not in the ‘renv’ project library. As a consequence, its loading seems to be skipped in the subprocess launched by renv::upgrade(). In itself, this is fine: in fact, ‘rprofile’ is designed to be loaded via try(rprofile::load()) inside .Rprofile to avoid breaking when it is not installed.

[kevinushey]

I suspect that renv::upgrade() launches a subprocess which doesn’t inherit the options of the parent R process. In fact, using the environment variable RENV_CONFIG_AUTOLOADER_ENABLED instead of the option works around this issue.

That's exactly correct -- I'll see if we can forward the option in this case.