R hooks give misleading warning when {renv} package versions differ

The implementation in #1799 relies on a globally installed version of the {renv} R package (with 0 dependencies). When the version of this installed package is different from what is provided in renv.lock (which is managed by the hook author), a warning like the following is displayed when hooks are ran:

renv 0.13.0 was loaded from project library, but this project is configured to use renv 0.12.5.
Use `renv::record("renv@0.13.0")` to record renv 0.13.0 in the lockfile.
Use `renv::restore(packages = "renv")` to install renv 0.12.5 into the project library. 

This is very misleading since these commands had to be ran in env_dir of the hook, not in the directory from which the hook is invoked and if the user were to run the above command, it would in the worst case change the virtual environment of the project from which the hooks are invoked - and in no case fix the warning.

The solution to this is IMO, as mentioned in https://github.com/pre-commit/pre-commit/pull/1799#issuecomment-792697793, to require the hook authors to provide the activation script renv/activate.R in the hook repo in addition to renv.lock, as recommended for collaboration per the docs of {renv} (.Rprofile can be omitted since all it contains is a call to renv/activate.R). This will boostrap the right version of {renv} installation into the virtual environment used for the hook. This approach fixes a few other problematic aspects of the current implementation in addition to the above:

• {renv} would no longer be installed into the global package library. We could go from a 99% insolation to 100% isolation from the global library.
• {renv} is not required in the global package library, i.e. the hooks still work if it was for some reason uninstalled or not available after a major R version update (where the user starts off with an empty library).
• https://github.com/pre-commit/pre-commit/pull/1799#discussion_r576345988 would not be an issue anymore, i.e. on linux, non-root users would no longer be required to have installed any package to make the hooks works.

If you agree, I can make a PR to try to implement this. For local hooks, we need to make sure to populate the directory renv/ in env_dir with activate.R in analogy to what the hook author would provide in his repo. Currently, pre_commit.store.Store.make_local() can only put files in the root of env_dir so this would require making the function slightly more general and add "renv/activate.R" to pre_commit.store.Store.LOCAL_RESOURCES as well as creating empty_template_activate.R in pre_commit/resources. I believe allowing to place files in sub directories of env_dir with pre_commit.Store.make_local() can be achieved with just a few tweaks to the function (https://github.com/lorenzwalthert/pre-commit/commit/4218765fe45a7b5c6b23d807cca212abd7092541).

Sorry for the hassle, I should have done more testing and indicated concerns in #1799 after I converted from draft and all checks were passing.

[asottile]

@lorenzwalthert this is done / fixed right ?

[lorenzwalthert]

Sorry I can’t follow. The directory structure I have looks like this;

|- ~/.cache
   |- pre-commit
      |- repobtu95rmu         (hook repo, prefix.path())
         |- renv.lock         (provided by user)
         |- renv              (will be here if we ask the user to provide it in hook repo)
           |- activate.R      
         |- renv-default      (env_dir)
            |- renv           (created during install_environment())
               |- activate.R  (The file I proposed to copy from repobtu95rmu/renv)
               |- [... ]      (files populated during install_environment() with R code)
            |- renv.lock      (copied from repobtu95rmu)

What I don’t understand is:

• why you refer to the environment directory as ./renv in your comment above (because I believe it is renv-default). I don’t see how pre-commit can know about renv/ in renv-default/.
• we already have an unmanaged (= user provided) file in env_dir: renv.lock. I see that we remove env_dir withwith clean_path_on_failure(env_dir) when the installation fails, but I don’t see how this is a problem, since these files will be copied into env_dir on a new installation attempt in my understanding.

Anyways, I opened a PR in #1841 where I implemented my initial propose, so we can see if tests pass and we have actual code to reason about, maybe it’s easier to understand each other 😄.