Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

helper functions to bootstrap from renv.lock 2 #356

Open
wants to merge 43 commits into
base: main
Choose a base branch
from

Conversation

RichardJActon
Copy link

Resuming where we accidentally left off: #349

Partially addresses #5, this implements a "fast" inexact conversion from renv to nix environment description. It does NOT capture the exact package versions, just the R version and the list of packages in renv.lock, nor does it differentiate primary from transitive dependencies in renv.lock it simply lists all dependencies.

To Do

  • Finish testing on real world renv.lock examples, and handling any resulting edge cases
  • Do any updates need to be made to the README / other docs about this?

---

`renv_lock_pkgs()` provides the basic functionality of getting the list
of R packages present in an renv.lock file.
It does NOT handle the versions of those packages or transitive
dependencies not directly used in the project.
---

`renv_lock_r_ver()` retrieves the R version from an renv.lock file.
---

adds the `exclude_other_sources` option to `renv_lock_pkgs()` and
defaults it to TRUE.
This excludes packages from being returned if the do not have
"Repository" as their value for "Source" in renv.lock the and throws a
warning listing the excluded packages.
This should exclude packages from sources like github which are not
presently like to be packaged in nix.
---

add `renv2nix()` wraps `rix()` and populates `r_ver`, `r_pkgs`,
`git_pkgs`, and `local_r_pkgs` based on an `renv.lock` file.
---

The `return_rix_call` argument allows `renv2rix()` to return the call to
the rix function instead of evaluating it, this allows or debugging the
call.
…` information

---

The `renv_remote_pkgs()` function takes a single renv.lock package entry
as an argument, infers it's remote type and extracts the informaton
necesary for `rix()`'s `git_pkgs` argument.

This functionality was factored out of the `renv2nix()`, and the
`method` argument added `renv2nix()` to allow for a future
implementation of exact package version matching.
---

Returns a list of package information suitable to supply to the
`git_pkgs` argument of `rix()`
…ith type assertion handling

---

Ability to allow remote type inference with error for unsupported types
as well as to assert a remote type expected for all pkgs
simpler to work with than using logicals approach and fixes bug with NAs
in `r_pkgs` in the previous approach.
@RichardJActon
Copy link
Author

About excluding {renv} from default.nix (#349 (comment)), I'm not sure this is always a good idea.

I've been playing around with projects where both the {renv} and nix environment management are present and running an renv::snapshot() then using the resulting renv.lock to generate a default.nix via renv2nix() is quite handy to do on a local environment managed with nix.
This is especially the case when my remote system is still doing builds in CI based on the {renv} tooling and not nix yet, this lets me keep both up to date and approximately in sync.

I'd say if the {renv} package is in your renv.lock then it should end up in your default.nix. It's worth noting that {renv} does not necessarily end up in the lock file by default when you use {renv} to manage a project. I just happen to have picked a couple of examples where it is in there on purpose as I extract the version of {renv} I'm using in that project from the lock file to install the right version in the container my CI uses.

@b-rodrigues
Copy link
Contributor

Thanks for reopening @RichardJActon and sorry again! Next time I want to add changes, I'll open a PR against your branch !

@b-rodrigues
Copy link
Contributor

We can ignore the unit test not passing in CI, that's due to a known issue with Rcpp and R 4.4.2. A fix is coming to CRAN so this won't be an issue much longer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants