Use a .toml file to store settings #420
Conversation
|
Example toml file: default_toolchain = "nightly-x86_64-pc-windows-msvc"
version = "12"
[overrides]
"\\\\?\\C:\\Users\\diggs\\workspace\\multirust-rs" = "nightly-x86_64-pc-windows-msvc" |
|
|
||
| pub fn from_toml(mut table: toml::Table, path: &str) -> Result<Self> { | ||
| let version = try!(get_string(&mut table, "version", path)); | ||
| if !SUPPORTED_METADATA_VERSIONS.contains(&&*version) { |
There was a problem hiding this comment.
ISTM that "2" shouldn't be considered valid here since there's never been a settings.toml containing version 2.
There was a problem hiding this comment.
The upgrade to settings.toml is orthogonal to the metadata version: since it's lossless it gets converted automatically, so if you upgrade from an old version of multirust to rustup, it will result in a settings.toml file with a version of 2, and you will then be required to do a metadata upgrade.
There was a problem hiding this comment.
I see. Thanks for the explanation.
|
My only reluctance is that this commits us to deserializing a config file every time someone runs cargo or rustc, but I'm somewhat resigned to that fate. Most if this information must be read anyway so it could even be better to load it all at once. cc @alexcrichton Can you also add the telemetry flag? |
| let _ = utils::remove_file("version", &legacy_version_file); | ||
| let _ = utils::remove_file("default", &default_file); | ||
| let _ = utils::remove_file("overrides", &override_db); | ||
| } |
There was a problem hiding this comment.
Can you extract this into its own function?
|
Looks great. I do think it needs to take care to not read the file multiple times. Will you also add a test that this conversion works? A simple way to do it is to modify the files in |
|
I think that's everything! |
Yeah unfortunately |
|
@Diggsey ok, this looks fine by me. Before merging this big change and risking more breakage I want to get a build out that fixes the windows bustage. I'll merge after that. |
|
Great! |
|
☔ The latest upstream changes (presumably #434) made this pull request unmergeable. Please resolve the merge conflicts. |
brson
force-pushed
the
master
branch
2 times, most recently
from
1acdeb2 to
9830d33
Compare
| "a;nightly\nb;stable").unwrap(); | ||
| rustup_utils::raw::write_file(&config.rustupdir.join("telemetry-on"), "").unwrap(); | ||
| expect_err(config, &["rustup", "default", "nightly"], | ||
| "rustup's metadata is out of date. run `rustup self upgrade-data`"); |
There was a problem hiding this comment.
Why is this expecting an error message saying to run upgrade-data? Doesn't this upgrade happen silently?
I think this test should be tweaked just a little. Before writing the old metadata, first run the commands that correspond to the metadata, then write the metadata and delete the settings.toml file. Then run some rustup command to force the silent upgrade. Then run further rustc commands that verify that the metadata is intact - that rustc --version prints the right thing for the default and override (telemetry flag probably not worth testing explicitly).
There was a problem hiding this comment.
This is testing an upgrade from metadata version 2, ie. an old metadata version, for which we currently require an explicit upgrade (because it wipes the toolchains). I can add a separate test for just the toml upgrade, but it would be a subset of what is tested here.
# Conflicts: # Cargo.lock # src/rustup-utils/Cargo.toml # src/rustup-utils/src/lib.rs # src/rustup/config.rs
|
This is back up to date, just waiting on CI again. |
This doesn't bump the metadata version. Running rustup will silently convert your
version,defaultandoverridesfiles into a singlesettings.tomlfile.If your metadata version is older than "12" it will first be converted to the new format, and then rustup will require you to perform a metadata upgrade exactly as it would before.
This paves the way for storing additional information in the settings file (such as the host target).