search

ohdsi-studies / Covid19SubjectsAesiIncidenceRate

Extending on our previous work by Li et al. in understanding the incidence rates of adverse events of special interest (AESI) for COVID-19, this work will look at the rates of these AESIs in patients who had COVDI-19 disease.
https://ohdsi-studies.github.io/Covid19SubjectsAesiIncidenceRate/Protocol.html
2 stars 4 forks source link

verifyDependencies() assumptions and behaviour #16

Closed eminty closed 2 years ago

eminty commented 2 years ago

More of an interaction between verifyDependendencies() and the (current) dockerized study workflow; and hat tip to Marc for helping to sort this out.

VerifyDependencies() appears to assume you are in the same working directory as the renv.lock file, which may not be true?

It also doesn't appear to search across the full set of library paths for the package dependencies, (but of course R does at runtime).

I was getting errors about required dependencies not being present, even though they were, just in a different library (that was correctly on the lib path).

Setting verifyDependencies = FALSE allowed the package to run; which is probably not the desired behaviour.

(That said, we can look to determine if / why some of the libpath specification in the current docker workflow is needed).

ericaVoss commented 2 years ago

@schuemie I think that was our assumption (everything in the same working directory) - not sure why that doesn't work for docker. I guess it is something to keep in mind for the future, not necessarily to augment the current package?

Tagging @msuchard to keep in conversation loop.

schuemie commented 2 years ago

verifyDependencies() assumes the renv lock file is in the current working directory. From there on it just calls packageVersion() to get the current installed version, which, according to the R documentation, should search across all library paths.

May I propose that, for consistency, we require the current working directory contains the renv lock file as well as the renv library? That would avoid a lot of unwanted behavior.

eminty commented 2 years ago

Having the renv.lock file in the current working directory is easy enough.

I can't explain the behaviour at runtime with respect to not finding packages that are in libraries on the lib path. Will look to explore the requirements behind additional libpath specification in the docker image.