Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Add a minimal-rust-version flag to crates manifest #2751

Closed
dns2utf8 opened this issue May 29, 2016 · 9 comments
Closed

Proposal: Add a minimal-rust-version flag to crates manifest #2751

dns2utf8 opened this issue May 29, 2016 · 9 comments

Comments

@dns2utf8
Copy link

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

@killercup
Copy link
Member

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.

@alexcrichton
Copy link
Member

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!

@dns2utf8
Copy link
Author

dns2utf8 commented Jun 1, 2016

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?

@alexcrichton
Copy link
Member

Ah right now we don't have a Cargo-specific RFC repo it'd just be in the standard rust-lang/rfcs repo

@gnzlbg
Copy link
Contributor

gnzlbg commented Nov 18, 2016

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.


@dns2utf8

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.

@tmccombs
Copy link
Contributor

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.

@carols10cents
Copy link
Member

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.

@ehsanul
Copy link

ehsanul commented Feb 21, 2018

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

@estebank
Copy link
Contributor

@ehsanul the current RFC is rust-lang/rfcs#2495

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants