Upgrade rust toolchain and use new lockfile format #2620
Conversation
|
Alternatively we could also pin to |
Previously we were installing whatever was the latest version implicitly, and this would upgrade our rust toolchain whenever our docker caching happened to get busted before rust was installed. We now explicitly specify a version to install, and I've also upgraded this to the latest version. There is a slight change in the lockfile format, fixed in a follow-up PR, as to make it easier to pin to an earlier version if desired.
In rust-lang/cargo#7070 the lockfile format was updated, instead of a top-level `[metadata]` key that holds the checksums for dependencies, these checksums are now specified in-line with the dependency. Since we shell out to `cargo` for most things, and in our tests only explicitly check for the presence of the `sha` values, this change is fairly minimal. I've opted to remove the checksums in most of our fixtures, as they are not strictly needed in our tests. I could have left them in there and things would still pass (`cargo` will silently upgrade them to the new format), however it seemed noisy.
jurre
force-pushed
the
jurre/upgrade-rust
branch
from
adae6e9
to
1e4c384
Compare
There was a problem hiding this comment.
👍 as you can't argue with CI failing in main but 🤞 not this branch.
Can you walk me through the implications for someone on rust 1.37 / 1.47 today?
This PR seems to support the new style and remove support for the old; does that force users to upgrade? How will we handle old style lockfiles now?
Old style lockfiles will be upgraded to the new version by cargo (according to the changelog and I also verified this by running on an old lockfile). The new format was introduced in 1.38.0 (released on 2019-09-26) (according to that same changelog), so I expect most people will already be on that version. What's new in this version is automatically upgrading the lockfile, but I expect that few projects will be on an incompatible version? I don't know of a way to verify that though 🤔 |
|
Have we already been running the new version and upgrading users lockfiles without too much issue feedback? Inclined to just go for the new version so we don't need to do the whole dance to install multiple version and switch at runtime. |
|
@jurre awesome, thanks! A regression test that upgraded an old style fixture to new would have been warm/fuzzy, but your description is 💯 - the old style has been out for so long I don't think it's worth maintaining. |
Previously we were installing whatever was the latest version
implicitly, and this would upgrade our rust toolchain whenever our
docker caching happened to get busted before rust was installed.
We now explicitly specify a version to install, and I've also upgraded
this to the latest version.
In rust-lang/cargo#7070 the lockfile format was
updated, instead of a top-level
[metadata]key that holds thechecksums for dependencies, these checksums are now specified in-line
with the dependency.
Since we shell out to
cargofor most things, and in our tests onlyexplicitly check for the presence of the
shavalues, this change isfairly minimal.
I've opted to remove the checksums in most of our fixtures, as they are
not strictly needed in our tests. I could have left them in there and
things would still pass (
cargowill silently upgrade them to the newformat), however it seemed noisy.