I'm trying to run Rocket but I'm falling at the first hurdle. When trying to cargo run, I get the following error:
error: failed to run custom build command for `pear_codegen v0.1.2`
Error: Pear requires a nightly or dev version of Rust.
Installed version is: 1.33.0 (2019-02-28). Minimum required: 1.31.0-nightly (2018-10-05).
I'm new to Rust, but coming from other languages this makes no sense whatsoever. It needs version 1.31.0 as a minimum but I have version 1.33.0 installed.
What am I doing wrong?
If software requires a nightly build of Rust, no stable version of Rust can be substituted: you are required to use nightly.
The nightly channel of Rust is a superset of stable Rust. Features that are not yet complete or simply haven't proven their value are included in nightly builds of Rust. You opt into using a given feature via a crate attribute.
These unstable features may completely change or even be removed at any time. Said another way, an unstable feature is never guaranteed to exist in any particular Rust stable version.
If it helps, you can think of nightly versions as an "alternate reality" track of development. The version number of nightly is only a loose indicator of where they exist in time; the compilation date and git commit hash are much more informative.
I would have thought the nightly code from 1.31.0 would be pushed into the stable 1.31.0+ versions once tested
This is how the beta channel works — anything in 1.x.y-beta will be in 1.x.y-stable (assuming no major emergency occurs).
See also:
What is the stabilization process?
error[E0554]: #![feature] may not be used on the stable release channel Couldn't install racer using cargo
What is a crate attribute and where do I add it?
You aren't doing anything wrong, Rocket just requires Nightly builds so it has access to newer features of Rust that might've not stabilized yet.
You can opt to only use a Nightly build for your Rocket project, per the documentation:
rustup override set nightly
Getting started guide
Related
I've built a rust toolchain using someone else's repo, and it contains
a configure line I'm not familiar with: --release-channel=nightly
After I build and install the toolchain it reports its version as:
rustc 1.57.0-nightly (f1edd0429 2021-11-29)
while the standard off the shelf install of 1.57 reports its version as:
rustc 1.57.0 (f1edd0429 2021-11-29)
What does the nightly suffix mean in this version string?
Nightly is an unstable, unfinished, experimental version of Rust.
The name comes from the fact that literally every night a new "nightly" version is automatically released from whatever happens to be in the rust-lang repository at the time.
The nightly version allows use of Rust features that are still work in progress, special unstable features that are private to the compiler or the standard library, or even features that were failed experiments and will never be available in the stable releases of the Rust language.
Nightly versions may crash, may miscompile code, may stop working at any time. There is absolutely no warranty about them. Do not use them unless you specifically want to test the latest, unfinished Rust language features.
There's one case where users may hear about "nightly" features: when they use an outdated version of the compiler.
When an old Rust version sees language features "from the future", it may ask you to enable nightly features to use the code. This is misleading. You should upgrade Rust to the latest stable version instead of using nightly.
I want to install a package and all its dependencies as they were at a specific date and time in the past.
I need to use a slightly older version of rustc-nightly, and therefore I need to make sure that all dependencies pulled by cargo install compile against that old version of the compiler.
Currently, when I specify the version of the top-level package to install, it still seems to pull the latest version of some dependencies, which don't build with the old compiler.
No, this is not possible.
Your best options are:
Upgrade the compiler. If you "can't" do this, evaluate why you can't and decide how much benefit you are getting from that.
Add the dependencies to your own Cargo.toml pinned to an older version that does work.
You can try forking the crate index and rolling it back, but there's no guarantee that will work either.
seems to pull the latest version of some dependencies
Yes, most libraries specify dependencies with a semver-compatible range, such as my-library = "1.0". This will allow any version from 1.0.0 to 1.x.y.
Unfortunately, there's no consensus on whether requiring a new version of Rust constitutes a semver-breaking change yet.
See also:
What exactly is considered a breaking change to a library crate?
How to generate Cargo.lock based on last month's crates.io?
If I find a crate I'd like to use, how can I find out with which versions of Rust the crate works as expected?
Right now, you either read the crate's documentation or test it yourself. Many larger crates test against an older pinned version of Rust in CI when they make a stability claim.
There is a proposed RFC that would add the Rust version to the Cargo.toml file.
I've been developing a project in Rust for awhile. A few days ago I ran cargo update and a whole bunch of my dependencies got downgraded, and I haven't been able to figure out why. I created a new project and have found that if the dependencies in Cargo.toml are just
[dependencies]
mysql = "*"
it builds with the latest mysql (11.3.0) as I would expect. If I add
byteorder = "1"
then run cargo clean/cargo update, mysql gets downgraded to 8.0.0.
Any help figuring out why the byteorder dependency is making Cargo downgrade mysql or how to stop it from doing so would be appreciated.
how to stop it from doing so
This is the easy part: don't use wildcard versions. The chances of your code working with literally any version of that crate that has ever been published is, on average, zero.
why the byteorder dependency is making Cargo downgrade mysql
This is actually really hard to answer. Picking dependencies is an NP-hard problem. Since most programmers don't care to wait that long, there are heuristics and preferences and shortcuts in every dependency manager. I don't know all the nuances of Cargo's algorithm, so most of this is educated guesses or investigation.
You've told Cargo "I don't care what version mysql to use" by saying mysql = "*". Cargo is now free to use whatever version it wants to, a very flexible requirement.
In this case, mysql 11.3.0 has chosen to require byteorder = "~1.0". That does not allow byteorder 1.1.0. Some aspect of the dependency resolution sees this and says it'd be better to allow your crate to have version 1.1.0 of byteorder, even if that means that mysql needs to be downgraded to a non-conflicting version. The important thing is that version 8.0.0 was the last version that only requires byteorder 0.5.3.
If you try to force both to the current versions, you'll see this:
error: failed to select a version for `byteorder` (required by `mysql`):
all possible versions conflict with previously selected versions of `byteorder`
version 1.1.0 in use by byteorder v1.1.0
possible versions to select: 1.0.0
However, you can get almost fully updated:
[dependencies]
mysql = "11.3.0"
byteorder = "1.0.0"
I'm not fully sure why Cargo will allow you to have version 1.1 and 0.5 at the same time but not 1.1 and 1.0, but my guess is that a heuristic is to have only one semantic major version of a given crate.
Future enhancements to Cargo will likely introduce the concept of "public" and "private" dependencies, which will likely change the resolution algorithm as well as make this case better as byteorder is probably an internal dependency of mysql and you don't need to match it.
Just started learning Rust. On Wikipedia it says pre-alpha stable version is not recommended because the language moves fast. But is 1.0-alpha stable now to use for learning?
I wanted to install Rust using homebrew on mac, but it only has the 1.0-alpha version.
Start now, and use the nightlies as suggested by Dietrich. The biggest conceptual chunks of the language (such as lifetimes and ownership) are extremely unlikely to change between now and 1.0-beta or 1.0. The biggest "issues" you will experience will be with the standard library - what features it exposes and how. At worst, that means you have to change some code and read a changelog each time you update the compiler.
As for how to install it, homebrew has a --head option you can use to install the newest code. You may just want to download the version from the website though or use rustup.sh.