Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
currently all AI generated, but tracking here - the core need is to be better able to properly generate a renv.lock file suitable for other tooling that needs that off of an rproject.toml/rv.lock.
Summary
This PR adds an
rv renv lockworkflow so anrvproject can emit a renv-compatiblerenv.lockfor downstream tooling that expects the renv format.The generator uses
rv.lockas the source of truth for resolved package sources and dependency relationships, then enriches that data with installedDESCRIPTIONmetadata from the synced library so the output looks like a real renv lockfile instead of a lossy export.The branch also adds:
Repositoryfield comes fromrproject.tomlrather than server-stampedDESCRIPTIONvalues likeRSPMrenv.lock--dry-runreport for reviewing what an exclusion set would removerenv::snapshot()baselineThe goal here is interoperability, not to make renv the source of truth.
rv.lockalready knows which packages were resolved and where they came from, but it does not carry all of the package metadata that renv writes intorenv.lockentries. To produce something renv-compatible, this implementation reads the installed library'sDESCRIPTIONfiles and merges those fields with source metadata fromrv.lock.That design gives us:
rvremains the canonical project manager and lockfile formatrenv.lockbecomes an export artifact that can be generated on demandIn particular, the git metadata fields are required for other tools restoring packages that come from git. As rv does not inject that into the description, without that making it into the renv.lock, other tools cannot restore packages from git the same way they come into rv
Design Notes
Lockfile generation
rv renv locksubcommand.rv.lockand a synced library, because the generator readsDESCRIPTIONfiles from the installed library path.How package metadata is built
rv.lockprovides source information and dependency structure.DESCRIPTIONfiles provide package metadata such asTitle,Authors@R,Depends,Suggests, and similar renv-visible fields.DESCRIPTIONfields are converted into renv-style JSON arrays.Source mapping
Source = "Repository"and use the repository alias fromrproject.toml.Remote*metadata from the resolved git source.RUniversepackages are exported as repository packages with extra remote provenance fields.Source = "Local".Repository field override
One of the explicit fixes in this branch is that generated repository entries should not leak server-stamped
Repositoryvalues fromDESCRIPTIONfiles.For example, a package installed from Posit Package Manager may carry
Repository: RSPMinDESCRIPTION, but the generatedrenv.lockshould use the configured alias fromrproject.toml, such asCRAN. The same logic applies to custom/internal repositories.Excluding packages from the export
The tip commit adds
--exclude-pkgsand--dry-runfor cases where we want a slimmer exportedrenv.lock, especially around dev-only top-level packages.The exclusion design is intentionally conservative:
rproject.tomlcan be excluded--dry-runreports direct exclusions, transitive removals, and retained shared dependencies without writing a filecommands
Write to an explicit path:
Generate a reduced export that omits dev-only top-level packages where possible:
Preview the exclusion impact without writing
renv.lock:Machine-readable dry-run output: