provide exported functions for interacting with lockfiles #1438
Conversation
| @@ -416,7 +416,7 @@ local({ | |||
| on.exit(do.call(base::options, saved), add = TRUE) | |||
| } | |||
|
|
|||
| catf("* Downloading from GitHub ... ", appendLF = FALSE) | |||
| catf("* Downloading version %s from GitHub ... ", version, appendLF = FALSE) | |||
| #' @rdname lockfile | ||
| #' @export | ||
| lockfile_modify <- function(lockfile, | ||
| ..., |
There was a problem hiding this comment.
Not used internally, but I thought this might be useful for end users (e.g. a way to explicitly set the repositories in a lockfile)
There was a problem hiding this comment.
Oh sorry. That's there intentionally so we can:
- Force some arguments to be named,
- Add new arguments (in any order) in a backwards compatible way.
There was a problem hiding this comment.
(but maybe I should add renv_dots_check() to warn about unused arguments)
There was a problem hiding this comment.
Yeah, I think if you use ... for this purpose, you need to error if there's anything in them.
There was a problem hiding this comment.
Ok; I made that change on main.
| @@ -96,7 +96,80 @@ | |||
| #' Note that the `Name` field may be empty. In that case, a project-local Python | |||
| #' environment will be used instead (when not directly using a system copy of Python). | |||
| #' | |||
| #' @inheritParams snapshot | |||
There was a problem hiding this comment.
I'd suggest adding a "for expert use only" caution somewhere.
|
Maybe remove |
I did indeed do that 🙂 |
TBH I'm still on the fence on whether we should provide all these methods, or a single function
lockfilethat returns the "API" object as we did before.