You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, renv.lock files can become bloated because they store all dependencies, metadata, and sources. A minimal lockfile containing only package names and versions would be useful, especially for Docker-based deployments or lightweight version control.
Could an option to renv::snapshot(), such as:
renv::snapshot(minimal=TRUE)
be added, which would generate a lighter renv.lock file with only explicitly used packages and their versions, without extra metadata?
Is there a specific motivation for wanting a more minimal lockfile? See also from NEWS:
* `renv` now includes additional package DESCRIPTION fields in the lockfile.
This can be useful for validating the provenance of packages recorded in the
lockfile, and also for applications using `renv` which would like to
recompute the hash used for package caching from the lockfile itself.
If needed, old-style lockfiles can be generated by setting the option
`options(renv.lockfile.version = 1)`. Note that this version of `renv`
remains compatible both with the older (minimal) lockfiles, as well
as with the newer lockfiles in this release. (#2057)
There is no specific motivation, other than the will to generate a file closer to something like requirements.txt from Python. Your suggestion answers my question.
Currently, renv.lock files can become bloated because they store all dependencies, metadata, and sources. A minimal lockfile containing only package names and versions would be useful, especially for Docker-based deployments or lightweight version control.
Could an option to
renv::snapshot()
, such as:be added, which would generate a lighter renv.lock file with only explicitly used packages and their versions, without extra metadata?
The output could be for example:
Obtaining such an output currently requires a custom script like:
Thanks for considering it.
The text was updated successfully, but these errors were encountered: