I'm trying to set up an alternate registry that holds private packages. The
.crate files for those private packages are built and managed through an external system, which may sometimes re-generate the
.crate file even though the crate and its metadata have not changed. But that re-generation also changes the checksum compared to what is in the
Cargo.lock, so any subsequent call to
cargo will fail with a checksum mismatch.
Unfortunately, as things stand today, it doesn't seem like there's a great way to work around this problem except to blow away the
Cargo.lock entirely (which also affects the checksums for
crates-io packages), or to parse and patch the
Cargo.lock file manually (which is obviously error-prone and a pain).
I see two possible ways to remedy this situation, and am curious to hear arguments for and against each one.
The first option is fairly "coarse", but I suspect it applies to many real-world uses of alternate registries. Since I completely control this alternate registry, I trust its build artifacts, and therefore I should be able to tell cargo not to worry about checksums for this registry only. Something like
[registries.alternate-registry] # ... verify-checksums = false
I had hoped to be able to approximate this by writing
<none> into the checksum field in the alternate registry index, but that hits the other checks for checksum mismatches in cargo.
The second option is to have a fine-grained mechanism for selectively updating the checksum for specific packages. Something like:
$ cargo update --allow-checksum-mismatch \ --registry alt-registry \ -p 'rebuilt:1.0.3' -p 'also-rebuilt:2.2.1'
This would set
also-rebuilt to version
2.2.1 in the registry respectively, and allow the checksum to change if the version stayed the same. Something more concise would be nice, but at the same time this is something we'd want users to be very aware of using, so maybe making it this verbose is a feature?