Proposal: Add a `minimal-rust-version` flag to crates manifest
dns2utf8 opened this issue · 9 comments
Hi all
Rust is introducing new keywords every now and then. Up until now the community just upgraded to the latest compiler within days, but this will change as soon as the compiler is installed with the package manager of the users distro.
Currently there seem to be only two distros providing a package for rust:
- Arch currently 1.9, will 1-3 days after a new release of rustc so not a problem
- Debian currently 1.8 in testing, 1.9 should land in unstable soon (something between 2 and 20 days according to the tracker)
I propose a minimal-rust-version for the manifest to guard against scenarios like this:
Crate A with version 1.3.0 would like to add a new feature, e.g. #[deprecated]
- For a new compiler this would be only a patch, no change in functionality => 1.3.1
- For an older compiler this would be a breaking change => 2.0.0
What do you think?
Regards
dns2utf8
I would suggest using a more generic term than minimal-rust-version in light of possible alternative compilers in the future. How about compiler = "rustc >= 1.8" which would allow more complicated version expressions (like rustc >= 1.8 AND rustc < 2.0) and also additional keys in the future, e.g. (rustc >= 1.8 AND cargo >= 0.9.5) OR future-rust-compiler-using-black-magic >= 1.0.
Thanks for the report! This has been brought up a few times before (#1214, #837, #1044, #967), but I'm not sure enough has changed to work with this just yet. Right now it would basically amount in a fancy error message indicating "this compiler won't work", and it wouldn't really be used for anything else.
That is, you specifically don't have a guarantee that the crate actually builds and works on any version of Rust, you'd just have to test and find out. This could perhaps one day affect resolution as well where if you are targeting Rust < 1.4 then you wouldn't accidentally pick up crates which explicitly require > 1.4, but even then there are no guarantees as all crates may not be annotated as such.
Overall I suspect that we'd want to flesh this out in an RFC (or something similar) before adding this to Cargo. Concretely, I'd want to see if we can get any hard guarantees from this, as that would definitely help justify an implementation!
I read the other issues and the essence there is to fix the compiler version.
But that could result in a dead-lock-like state where some crates request 1.8 and others 1.7.
The same could happen with a upper and a lower bounary.
Since the rust compiler guaranties it will be able to compile anthing since 1.0 newer compilers should allways be able to compile old code. Atleast in the 1.X.Y releases.
I am thinking about writing an RFC, would that be a regular rust RFC or a cargo RFC?
Ah right now we don't have a Cargo-specific RFC repo it'd just be in the standard rust-lang/rfcs repo
Quoting from #3298: It would be nice for those working with particular snapshots of nightly if it would be possible to fix the toolchain in the Cargo.toml file, e.g., something like:
[toolchain]
channel = nightly
date = 2016-11-13
host = x86_64-apple-darwin
and if cargo would use rustup to get the appropriate toolchain.
Since the rust compiler guaranties it will be able to compile anthing since 1.0 newer compilers should allways be able to compile old code. Atleast in the 1.X.Y releases.
This is true for the stable release channel only, but some crates require nightly, and some crates require specific nightly versions.
This hasn't had a lot of activity recently. But one example of where this would be helpful can be found here: sharkdp/fd#43.
The fd project specifies a minimum rust version in the README. But if someone fails to read that, it isn't obvious from the compile error that the problem is they need a newer version of rustc. Just having a better error message if someone tries to compile with an older version of rustc would be useful. It would also be nice to show on crates.io which rust version is required for a crate.
There have been a number of RFCs on this issue, none of which have been merged yet:
Given that it's clear this request needs an RFC, I'm going to close this issue.
All of those RFCs are now closed and I couldn't find any others that are still open. There is this related one that's open, but seems to be about cargo versioning, not rust versioning: rust-lang/rfcs#2182
@ehsanul the current RFC is rust-lang/rfcs#2495