search

NCC-CNC / wheretowork

Interactive application for systematic conservation planning
https://NCC-CNC.github.io/wheretowork
Other
8 stars 2 forks source link

renv and Suggests #381

Closed DanWismer closed 2 months ago

DanWismer commented 2 months ago

@jeffreyhanson wondering what you are thinking about how the current version of renv handles Suggests?

They treat these packages as not part of the core project and therefore they are not included in the renv.lock file. However you can track them using renv::snapshot(dev=TRUE), but it then complains that the project is out of sync because you have packages installed and recorded, but not use. In order to get around that, they say add the needed libray(package) call in a script called dep.R. I am not really a fan of that.

What I am thinking is to accept that the renv.lock only includes dependencies for running the application (Imports, Depends, LinkingTo). This does reduce bloat.

And then the workflow for doing development would include

  1. Clone the repo
  2. run renv::restore()
  3. run renv::install() on each of the packages in the Suggests, making sure you install the right version number. And this would be a manual thing (not great).

Wondering if you had any ideas on this?

jeffreyhanson commented 2 months ago

Yeah, this is a tricky conundrum. Just did some googling, have you looked project profiles in renv (https://rstudio.github.io/renv/articles/profiles.html)? It seems it might be useful here.

DanWismer commented 2 months ago

Yea that renv dev profile looks is an answer. Trying to implement with not much success.

I have renv::active(profile="dev"). Now I am simply trying to do renv::snapshot(type="explicit", dev=TRUE) . This gives me a huge list of packages to reinstall before snapshooting.

DanWismer commented 2 months ago

hmm instead I did renv::snapshot(type = "all") and it seemed to work.

I am also removing rsconnect from Suggests because I can't get its Biobase dependencies to install. Its not on CRAN?

jeffreyhanson commented 2 months ago

Ah - haven't used renv profiles before so I won't be much help sorry.

Yeah, removing rsconnect sounds good. I originally inlcuded that so we could have a non-production version of the app on shinyapps. However, since the app is too big for shinyapps, that's not possible and rsconnect is unused.

DanWismer commented 2 months ago

sounds good, the only call I see to it is in the golem dev folder 03_deploy.R script. I am wondering if renv even sees that folder?

jeffreyhanson commented 2 months ago

Hmm, probably? I can't remember if we have it configured to ignore it off the top of my head

DanWismer commented 2 months ago

In the DESCRIPTION we have >= for the package version. Should we just be putting = so that it uses the exact version?

jeffreyhanson commented 2 months ago

You could do that, but that will mean that users who install the WTW package to generate datasets for the tool will need those exact versions.

DanWismer commented 2 months ago

ok I think I got this profile thing working:

  1. renv::activate(profile = "dev")
  2. renv::settings$snapshot.type("explicit")
  3. renv::settings$ignored.packages(c("wheretowork", "gurobi"))
  4. renv::snapshot(dev=TRUE)

Weird is that I thought I could do: renv::settings$package.dependency.fields(c("Imports", "Depends", "LinkingTo", "Suggests")) then simply renv::snapshot(). However that gets me into a mess.

So instead, I have it to the default: renv::settings$package.dependency.fields(c("Imports", "Depends", "LinkingTo")) and need to call renv::snapshot(dev=TRUE) to get the packages in the Suggests into the lockfile.

... oh ok, I will keep it >= in the DESCRIPTION

jeffreyhanson commented 2 months ago

Ah interesting. Yeah sounds a bit tricky to set up, but great you got it working. Yeah, the ignored packages bit is needed since gurobi isn't on CRAN or Github.

DanWismer commented 2 months ago

With this we now have two renv.lock files to manage. One which is the "default" profile, renv::activate(profile = "default"). And the second which is the "dev" profile, renv::activate(profile = "dev") The "default" profile has all the dependencies which are required to run the application (Imports, Depends and LinksTo). This references the renv.lock file in the top level directory. The "dev" profile has all the dependencies which are required for both running the application and doing development work, such as running tests and creating the pkgdown site (Imports, Depends, LinksTo and Suggests). The renv.lock file for dev is located in renv/profiles/dev.

A little more complex, but I think its all we can do. At least this should take away some of the bloat when users install wheretowork for data prep. We just need to be very cautions that when the renv.lock file is updated on the "default" profile (production), it also gets updated on the "dev" profile. I have yet to find documentation on keeping those two renv.lock files synced. I think we would just have to manually do it with renv::snapshot. I guess it should tell us if the project is out of sync anyhow if there are changes in one environment or the other.

What I don't like is that switching between "default" and "dev" you need to run renv::activate(profile="..."), There is also a project argument with renv::activate. If you do renv::activate(project="default") by mistake, it gets everything into a mess and creates a new profile. And I find its easy to confuse project with profile. Just something to watch for.

DanWismer commented 2 months ago

... thought I had this figured out. My "dev" profile still says that I have packages installed, recorded, but not in use. I am thinking now of maybe just scratching all this. I think profiles is new and maybe needs to be tested more? That being said, if I do scratch this; when you clone wheretowork, and do renv::restore, it will only restore packages needed to run the app (Imports, Depends and LinkingTo). And then for dev work, you would need to install the packages in the Suggests, with the correct version number ex. renv::install(testthat@3.2.1.1) by hand.