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.

Sign up for GitHub

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

Jump to bottom

renv.lock package information fully specified #2057

Closed
aronatkins opened this issue Dec 6, 2024 · 2 comments · Fixed by #2059
Closed

renv.lock package information fully specified #2057

aronatkins opened this issue Dec 6, 2024 · 2 comments · Fixed by #2059

Comments

@aronatkins
Copy link
Contributor

It would be grand if the package details included in the renv.lock were sufficient to recreate the cache hash location for either Packrat or renv. In particular, in order to accurately compute cache hashes we need remote package details (GitHub repo, etc) and dependencies. Unfortunately, we need source-dependencies and LinkingTo dependencies separately, as LinkingTo is used to recursively compute hash locations.

Were the renv.lock to have all of these details, the manifest.json file would not need the full package description file contents. Additionally, the renv.lock could drop its Hash entry and accurately recompute it on the fly.

If the manifest.json does not need the full package DESCRIPTION, it means that we could consider deploying without a fully populated R library.

related: #884

The Packrat has implementation with all of its fields:
https://github.com/rstudio/packrat/blob/af3bed4d917461764926b56b90f6d511d16d4f58/R/cache.R#L25-L120

This improvement came up during a discussion about the Publisher.
@kevinushey
Copy link
Collaborator

The original motivation for the "minimal" lockfile records format was to make it easier to tweak by hand if necessary. In practice:

  1. I don't think many people actually do this,
  2. People could still edit lockfiles by hand; in practice, for a CRAN / repository record they'd just update the Version field anyhow.

Which is all to say, I think I'm board with doing this, and probably even just doing this by default.

Should we include only the fields that renv uses for hashing? Or should we consider including any and all fields which might be common to both source and binary packages?

@kevinushey kevinushey mentioned this issue Dec 12, 2024
Merged
@jrdnbradford
Copy link
Contributor

@kevinushey I can update inst/schema/draft-07.renv.lock.schema.json and add tests to ensure renv::lockfile_validate() handles the new lockfile. Current tests for renv::lockfile_validate() in #2059 pass because the schema allows for extra properties, so it's not strictly necessary that the schema update be done before or in conjunction with that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

include all required fields for hashing in lockfile rstudio/renv
3 participants
@aronatkins @kevinushey @jrdnbradford