Provide better way for API users to deal with unstable features

[dpc]

I'm trying Rust Edition 2018 RC1 on my project and part of it was removing cargo-features = ["edition"] line. Most tools works correctly, but both cargo-outdated and my own project that uses cargo as a library stopped working and print:

error: failed to parse manifest at `/home/dpc/lab/crev/crev-common/Cargo.toml`
caused by: editions are unstable
caused by: feature `edition` is required

or similar when opening workspace:

cargo::core::Workspace::new(&self.manifest_path, &self.config)?;

It looks like for whatever reason they didn't get the memo that cargo-features = ["edition"] is not required anymore.

It's a bit surprising since cargo on beta channel works just fine. Do I have to configure something in https://docs.rs/cargo/0.30.0/cargo/util/config/struct.Config.html ?

[dpc]

I guess this is related: kbknapp/cargo-outdated#141

But I've tried the workaround from there (calling cargo::core::enable_nightly_features()) and it didn't help.

[alexcrichton]

This isn't a bug in cargo the executable, nor is it really a bug per se in Cargo-the-library but moreso a feature request. In any case seems fine to discuss here!

The problem here is that the version of cargo-the-library that cargo outdated is using thinks that to use the edition key you need to have the edition feature listed. The enable_nightly_features function is not intended to solve this, it's a red herring.

The beta channel of Cargo is different source code than what's published on crates.io, only the stable channel's cargo-as-a-library is published. The beta channel Cargo doesn't require the edition feature to use the edition key. The stable channel, however, does.

This isn't a problem purely isolated to cargo oudated, though. Any subcommand that links to cargo-the-library will likely experience this. I think the best thing we can do is to add a specific function which is targeted at relaxing the restriction that nightly features need to be listed to use them. This function would never be called by cargo-the-binary itself. It would, however, relax the restriction that features need to be explicitly enabled.

This won't be a bulletproof solution but it would hopefully be a better solution than what we have now! For the time being there's unfortunately not a great solution otherwise that I know of :(

[joelgallant]

See kbknapp/cargo-outdated#141 which is relevant, specifically cargo-outdated needs to carry the cargo-features into it's Manifest struct and deserialize with it, since cargo the library requires it.

[alexcrichton]

@joelgallant I believe that's the same issue as this one, which should be solved by my above comment

[vn971]

work-around (nasty one): comment out the edition line in Cargo.toml, run cargo outdated, uncomment back. I don't know how dirty it is, but it works.

[naturallymitchell]

I have the same problem with cargo-tree

[dwijnand]

I think the best thing we can do is to add a specific function which is targeted at relaxing the restriction that nightly features need to be listed to use them.

Sounds like it would be an escape hatch that would undermine the point of having unstable features.

From the conversation in sfackler/cargo-tree#56 I wonder if we can either:

1. identify that the feature checking is from a plugin, and then suggest upgrading the plugin; or
2. maybe compare against the plugin's libcargo version with cargo's libcargo version and explicitly warn that, and suggest upgrading (or opening an issue?)

[gabridome]

Just for reference [Solved]:

I had a similar problem:

cargo build --release
error: failed to parse manifest at `/home/bitcoin/electrs/Cargo.toml`

Caused by:
  editions are unstable

Caused by:
  feature `edition` is required

this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["edition"]` to enable this feature

I ran:
rustup update

The rustc version was upgraded to 1.32.0

  stable-x86_64-unknown-linux-gnu updated - rustc 1.32.0 (9fda7c223 2019-01-16)

This solved the issue.

[vn971]

@gabridome tried right now, it still doesn't work for me if edition is specified in Cargo.toml...

[dwijnand]

@vn971 update to cargo-outdated 0.8.0, it was released a couple of weeks ago: https://crates.io/crates/cargo-outdated/0.8.0

[gabridome]

@gabridome tried right now, it still doesn't work for me if edition is specified in Cargo.toml...

Yes. In my case it worked.
4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[vn971]

@dwijnand @gabridome it works for me as well now, thanks! The trick was indeed to update cargo-outdated itself, e.g.:

cargo install --force cargo-outdated