setup-deps fails for packages with renv on Fedora containers

[ezraporter]

When running rhub_check() for Fedora platforms, the setup-deps step fails for me when trying to locate pak:

https://github.com/CHOP-CGTInformatics/REDCapTidieR/actions/runs/8649035798

Rhub v2 is working great for all other platforms. I tested at least one other linux container (clang-asan) so this doesn't appear general to all linux containers vs. other platforms.

I suspect the issue is with renv causing pak to be installed in a place that library(pak, lib.loc = Sys.getenv("R_LIB_FOR_PAK")) can't detect.

I'm using rhub_2.0.0 from CRAN.

[gaborcsardi]

I am surprised that renv projects work at all, TBH. I am a bit unsure what we should do with renv projects, because there is a tension between using the package versions from the renv.lock file, and running R CMD check, which for many checks assumes that the packages are latest ones from CRAN.

I assume you'd want to install the package versions from the renv.lock file?

[ezraporter]

I assume you'd want to install the package versions from the renv.lock file?

Actually the opposite. We use rhub for running checks on multiple platforms before submitting to CRAN. We want to test against all the latest CRAN versions of dependencies as CRAN would. For our purposes it would be good enough to have an option that deactivates renv before running any checks.

For context, we use renv with package projects so developers can all have a consistent dev environment. In CI and pre-release checks though we want to test against the latest versions of everything since users don't care what our dev environment looks like.

[gaborcsardi]

That makes sense and it should not be too hard to implement.

[ezraporter]

Great! Thanks so much!

[gaborcsardi]

So, it seems that all renv::deactivate() does is deleting the .Rprofile file? Which is great, because then we can just delete that, and don't need to install renv to call renv::deactivate().

[ezraporter]

That sounds basically right although renv::deactivate() looks to possibly be doing a bit more to avoid disrupting an existing .Rprofile. You wouldn't have any complaints from me if you implemented by just deleting the .Rprofile though.

Understandable if you didn't want to rely on this but renv's default behavior is to try to install itself when R starts if it isn't installed already so you could run renv::deactivate() and not have to worry about installing it as a separated step.