renv 1.0.0 check on startup can lead to long session loading time

[michalovadek]

if an .*ignore file is missing or misspecified, loading an R project with renv that contains many files will take a long time because renv 1.0.0 checks all files at startup by default, without a prior warning or prompt (see also discussion here: #1181 (comment))

How I replicated the issue: I created a new R project in a new directory and created 100 000 dummy .txt files in subdirectory data. Opening the project hangs RStudio seemingly until the files are scanned. Adding data to .gitignore "fixes" it.

I think the user should be prompted whether they want to do the startup check if it involves a high number of files, otherwise it should be skipped. At very minimum they must be informed, as when running renv::status(). In a complex project it took me a while to figure out what was causing the slow loading time and at first did not realize this was related to updating renv to 1.0.0.

sessionInfo():

R version 4.2.3 (2023-03-15 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.utf8 LC_CTYPE=English_United Kingdom.utf8
[3] LC_MONETARY=English_United Kingdom.utf8 LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.utf8

attached base packages:
[1] stats graphics grDevices datasets utils methods base

loaded via a namespace (and not attached):
[1] compiler_4.2.3 tools_4.2.3 renv_1.0.0

[kevinushey]

We do display the following on renv::init():

> renv::init()
A large number of files (100000 in total) have been discovered.
It may take renv a long time to crawl these files for dependencies.
Consider using .renvignore to ignore irrelevant files.
See `?renv::dependencies` for more information.
Set `options(renv.config.dependencies.limit = Inf)` to disable this warning.

We suppress output like this here, though:

renv/R/load.R

Line 844 in 2d62bfa

renv_scope_options(renv.verbose = FALSE)

[michalovadek]

even if there is a case for suppressing other types of output, I would say here the default option should be to display it whenever there is a chance the function will take a while to run. Since renv::init() is not run manually most of the time (I suspect?), the user actually does not know what's causing the hang.