Proposal: Specify version of Rust platform, and lock for applications

[emk]

First, some use cases:

• ACME, Inc. has a large Rust application hosted on Heroku using a Rust buildpack. The application is a cash-cow: It earns a lot of money, and it has a lot of users, but it's only updated rarely. Six months after the last update, a critical bug is discovered. A two-line patch is produced, and it needs to be pushed to production.
• Rustalicious LLC is a boutique software consultancy specializing in Rust applications. They help maintain ACME's cash cow application. They're also working on Rust projects for 3 other clients, in varying stages of active development and maintenance.

In these examples, both ACME and Rustalicious need to control when they upgrade their Rust toolchain. ACME is trying to push an urgent fix to production, but they haven't touched the codebase in 4 Rust releases, and they don't have the time to upgrade to the lastest Rust compiler and verify that nothing is broken. They want to make a two-line fix using their old toolchain.

Rustalicious wants to use the latest and greatest Rust compiler for everything, because it's shiny. But they have multiple maintenance mode clients who depend on different versions of the Rust platform. So they potentially need to install multiple versions of Rust side-by-side, and manage them using a specialized tool.

Prior art: Bundler + buildpacks + RVM

In the Ruby world, it's possible to use Gemfile to specify the version of Ruby that should be used with an application:

`ruby '1.9.3'`

This information is read by Heroku's Ruby buildpack, and by various third-party tools like RVM that manage multiple, parallel Ruby implementations.

Proposed solution: Treat rustc and the standard libraries like any other versioned dependency

rustc and the standard library are an actual dependency for every Rust application. So it might be reasonable to specify their version numbers somewhere in Cargo.toml:

rust = "1.1.2"

This could go either in the package section, or possibily even in the dependencies section. It could potentially allow full version specifiers, and possibly even be recorded in Cargo.lock like any other dependency.

What would Cargo do with this information?

Two possibilities come to mind:

1. Verify that all packages can be build with the specified version of Rust, and if not, give an error message explaining the constraints. This would offer significant value to ordinary Cargo users, because they'd get comprehensible messages telling them when they needed to upgrade their compiler, instead of random error spew from one of the libraries they're using.
2. Store an exact version in Cargo.lock.

Third-party tools might also read this information to configure deployment servers (e.g., buildpacks), manage parallel Rust toolchains (e.g. RVM etc. for Rust), and decide which Rust version(s) should be used for continuous integration builds.

Alternatives

• Trust the compiler and standard libs to never have regressions.
• Store this information in a .rust_version file and coordinate between tool developers.

I'm not hugely attached to the details of this proposal, but I will need to address both the ACME and Rustalicious use cases in the future, with any luck. :-)

If it's useful, I'd be interested in contributing some code, but I'd need code review from the Cargo team.

[alexcrichton]

What oddly good timing you ask for a feature like this! We talked about this a lot at the work week, and our conclusions are summarized in @brson's RFC, could you take a look at that and see if it covers a lot of your concerns here?

[alexcrichton]

This is largely in the same vein as #837 in that for now I don't think that we're ready to make any commitments about the version of rust you're compiling with.

rust-lang/rfcs#507 has some information about how Cargo may apply heuristics to warn you if your version of Rust is out of date or perhaps affect package resolution to weed out those which don't work on the version of Rust installed, but these options are currently dependent on rustc support.

In general there's not a lot of action to take here right now I believe. I'd like to get some experience with stable Rust and/or our release cycle before we hasten in a system for juggling Rust versions (it may not even be necessary!)

As a result, I'm going to close this for now.