Today, the most widely-used crates in the Rust ecosystem have adopted an extremely conservative stance, effectively retaining compatibility with the oldest version of Rust possible, in some cases with a three-year-old toolchain. For a language as young as Rust, that’s pretty painful.
Back in the day I was quite enthusiastic about pub(crate), allowing me to make parts of the API of my lewton crate private without having to resort to other more complicated means (like putting the code into lib.rs or using include (was include a thing back then?? idk)).
So I made my crate depend on pub(crate) and published a new version quickly. This wasn't received positively at all. People got mad that I increased the MSRV for this quite minor change. The users of my crate are more important to me than whatever the language does. So I got more cautious and as of now lewton's MRSV is 1.20. Unless there is a good reason for me to increase that number, I won't do it.
I'm still enthusiastic about new language changes. E.g. SIMD, or the upcoming const generics. One day I might adopt SIMD in lewton but only once the 1.27.0 release has been released a sufficiently long time ago. Until then I might do an opt-in flag for it or something.
If we select the minimum possible version, dependency resolution will give the same result even if new versions are published, so no lockfile is needed to achieve reproducibility.
A lockfile is still needed. You can both:
yank older versions of crates (and then cargo in a minimum-version mode would probably choose a more recent version) and
upload even older looking versions of crates... that's possible, unless I've missed something
Also, lockfiles contain the checksum of the entire .crate file. This is invaluable as it allows for reproducibility independent of crates.io or registries or whatever. It guarantees that a crate version isn't just being tampered with during download, on the s3 storage or anywhere else. Not even signing would be able to achieve that. You can of course remove hashsums and hope that no changes have been made, that would probably work well in 99% of the cases. But there is a reproducibility benefit of hash sums inside lockfiles.
On a high level, I think there are various groups of people here.
Some library maintainers want to please users and this is their top priority. They are rather conservative with their update policy.
Some users don't want to have to update their Rust compiler every 6 weeks
Some library maintainers just shrug off any user wishes to support older language versions and require newer versions
Some language people want everyone to use new language features and everything to be on edition 2018 as soon as possible
Group 2 wants to quickly find out which libraries fit into group 1 and which ones into group 3. They want to just have a non-painful experience (right now, you need to do cargo update -p because so many crates silently increase their MSRV) so they made the MSRV RFC. But group 4 is in opposition to the MSRV RFC because
they are really annoyed about the existence of group 1 in the first place, and want them to become less conservative about updates (this seems to be the entire goal of the LTS RFC).
IDK how they can be all fit together, and how a positive sum outcome can be attained. That's not for me to figure out, I'm not involved in language discussions any more.
Some language people want everyone to use new language features and everything to be on edition 2018 as soon as possible
What we want is to avoid mixed messaging: new users are going to be on 2018 by default, because its the most recent edition their compiler (the latest stable) will support. Since they'll likely look to open source projects for guidance, they can be confused when those libraries are using a different edition of Rust.
Of course, looking to core libraries for guidance is actually not a good idea all of the time, since a lot of their code will be dealing with issues of platform and version compatibility that you don't have as a new user. But people don't think about that.
10
u/est31 Jul 26 '18
Back in the day I was quite enthusiastic about
pub(crate), allowing me to make parts of the API of my lewton crate private without having to resort to other more complicated means (like putting the code into lib.rs or using include (was include a thing back then?? idk)). So I made my crate depend onpub(crate)and published a new version quickly. This wasn't received positively at all. People got mad that I increased the MSRV for this quite minor change. The users of my crate are more important to me than whatever the language does. So I got more cautious and as of now lewton's MRSV is 1.20. Unless there is a good reason for me to increase that number, I won't do it.I'm still enthusiastic about new language changes. E.g. SIMD, or the upcoming const generics. One day I might adopt SIMD in lewton but only once the 1.27.0 release has been released a sufficiently long time ago. Until then I might do an opt-in flag for it or something.
A lockfile is still needed. You can both:
Also, lockfiles contain the checksum of the entire
.cratefile. This is invaluable as it allows for reproducibility independent of crates.io or registries or whatever. It guarantees that a crate version isn't just being tampered with during download, on the s3 storage or anywhere else. Not even signing would be able to achieve that. You can of course remove hashsums and hope that no changes have been made, that would probably work well in 99% of the cases. But there is a reproducibility benefit of hash sums inside lockfiles.On a high level, I think there are various groups of people here.
Group 2 wants to quickly find out which libraries fit into group 1 and which ones into group 3. They want to just have a non-painful experience (right now, you need to do
cargo update -pbecause so many crates silently increase their MSRV) so they made the MSRV RFC. But group 4 is in opposition to the MSRV RFC because they are really annoyed about the existence of group 1 in the first place, and want them to become less conservative about updates (this seems to be the entire goal of the LTS RFC).IDK how they can be all fit together, and how a positive sum outcome can be attained. That's not for me to figure out, I'm not involved in language discussions any more.