search

rstudio / renv

renv: Project environments for R.
https://rstudio.github.io/renv/
MIT License
999 stars 152 forks source link

implement mechanism for excluding certain packages from cache #107

Closed kevinushey closed 5 years ago

kevinushey commented 5 years ago

For example, someone might be working on a project with some packages which need to be compiled with special flags (e.g. for debugging, or special optimizations, and so on). However, we don't want these packages to enter the cache as one likely would not want the package to be used in other projects (or worse, to inadvertently be used in other projects when the 'default' build of the package is expected)

Fortunately, it's unlikely that the hashes of a locally compiled-from-source package would collide with that of a package retrieved from a remote source, because the Remote* fields are used when building the hash.

Unfortunately, there's no way for us to tell the difference between a package compiled from source with different sets of compilation flags -- the onus would be on the user to do something like change the Version in the DESCRIPTION, or similar.

I think the right solution is to ensure that we only cache packages which have a known source. If we cannot figure out where a particular package has come from, then we don't cache the package.

(note: in theory this does affect packages installed from remotes, since the user could change their R Makevars and so on between installations of packages from source)

copernican commented 5 years ago

This would indeed be helpful. One use case would be an in-development R package project that uses testthat. In this case, testthat.R will contain the call library(mypkg). This will be detected by dependencies() and recorded in renv.lock. But a package should not depend on itself. You could get around this by adding testthat.R to .renvignore or passing settings = list(ignored.packages = "mypkg") to init(), but it seems this is a common-enough use case that ignoring it by default would make sense. What do you think?

kevinushey commented 5 years ago

Agree 100% that should be handled by default in renv. Thanks!

kevinushey commented 5 years ago

This should be handled now -- for package projects (or rather, projects containing a top-level DESCRIPTION file in general), only that file will used be dependencies (since one would normally declare all required dependencies in that file). Let me know if that suffices for your use case.

rpodcast commented 5 years ago

This is a welcome addition! I am now packaging my shiny apps with golem and now I'm able to retroactively add renv to an existing app without complication.

kevinushey commented 5 years ago

That's awesome to hear :-)

copernican commented 5 years ago

I've tested this change and it appears to have resolved the issue. Thank you for the quick solution.