feat(generate-lockfile): Add unstable --publish-time flag #16265
Conversation
Implementation for rust-lang#5221 Use cases: - Improved reproduction steps using cargo scripts without including a lockfile - Debugging issues in the past - Manual stop gap for rust-lang#15973 Unresolved questions: - How do we compensate for the caveats, with one option being to leave this perma-unstable? - How should we deal with Summary `pubtime` parse errors? - How strict should we be on the Summary `pubtime` format? - Should we offer a convenient way of getting a compatible timestamp? Future possibilities: - Ability to lock to a timestamp with `cargo update` updating the timestamp (could be useful for cargo scripts) This seemed like the shortest path to testing the proposed `pubtime` index entries so we can unblock other work on it like rust-lang#15973. While this has some big caveats, the design is straightforward. In contrast, rust-lang#15973 has a lot more design questions (is this a resolver-wide setting or a per-registry setting, what formats are accepted, etc) that could slow down development and testing `pubtime`.
rustbot
added
A-cli
There was a problem hiding this comment.
While the long value_name makes the format very clear, the length is annoying
| fn datetime_completer(current: &std::ffi::OsStr) -> Vec<CompletionCandidate> { | ||
| let mut completions = vec![]; | ||
| let Some(current) = current.to_str() else { | ||
| return completions; | ||
| }; | ||
|
|
||
| if current.is_empty() { | ||
| // While not likely what people want, it can at least give them a starting point to edit | ||
| let timestamp = jiff::Timestamp::now(); | ||
| completions.push(CompletionCandidate::new(timestamp.to_string())); | ||
| } else if let Ok(date) = current.parse::<jiff::civil::Date>() { | ||
| if let Ok(zoned) = jiff::Zoned::default().with().date(date).build() { | ||
| let timestamp = zoned.timestamp(); | ||
| completions.push(CompletionCandidate::new(timestamp.to_string())); | ||
| } | ||
| } | ||
| completions | ||
| } |
There was a problem hiding this comment.
Didn't feel like writing my own parser for the sake of handling incomplete date, so I threw this together to at least make it easier to get the format correct so people can modify them from here.
| let mut ws = args.workspace(gctx)?; | ||
| if let Some(publish_time) = publish_time { | ||
| gctx.cli_unstable() | ||
| .fail_if_stable_opt("--publish-time", 5221)?; |
There was a problem hiding this comment.
Do we want to close the original issue and create a new one for tracking?
Benefit of this:
- Cargo team has full control over the issue. Original author won't delete that accidentally.
- Sometimes original issue has too many discussion. And we tend to use tracking issue for, well, tracking progress only.
| .arg( | ||
| clap::Arg::new("publish-time") | ||
| .long("publish-time") | ||
| .value_name("yyyy-mm-ddThh:mm:ssZ") |
There was a problem hiding this comment.
mm is ambiguous here 😆.
(no need to change)
| self.publish_time = Some(publish_time); | ||
| } | ||
|
|
||
| /// Sort (and filter) the given vector of summaries in-place |
There was a problem hiding this comment.
Probably expand this doc comment?
|
|
||
| This is a best-effort filter on allowed packages, including: | ||
| - packages from unsupported registries are always accepted | ||
| - only the latest yank status is respected |
There was a problem hiding this comment.
I had a hard time understanding this. Do need a test with yanked versions?
| /// incorrectly select a new package that uses a new index schema. A | ||
| /// workaround is to downgrade any packages that are incompatible with the | ||
| /// `--precise` flag of `cargo update`. | ||
| pub v: Option<u32>, |
There was a problem hiding this comment.
We should bump a index version, no?
There was a problem hiding this comment.
iiuc the index version represents incompatible versions of the schema. This change is forward and backwards compatible so it shouldn't need it bumped.
There was a problem hiding this comment.
I need to check our schema documentation to see if we list unstable fields.
If not, I need to note somewhere that we need to update it when stabilizing.
4 participants
What does this PR try to resolve?
Implementation for #5221, #15491
Use cases:
lockfile
This seemed like the shortest path to testing the proposed
pubtimeindex entries (#15491) so we can unblock other work on it like #15973.
While this has some big caveats, the design is straightforward.
In contrast, #15973 has a lot more design questions (is this a
resolver-wide setting or a per-registry setting, what formats are
accepted, etc) that could slow down development and testing
pubtime.How to test and review this PR?
Unresolved questions (deferred to the tracking issues):
this perma-unstable?
pubtimeparse errors?pubtimeformat?Future possibilities:
cargo updateupdating thetimestamp (could be useful for cargo scripts)