Rust 1.48 support broken by `resolver` field in packaged `Cargo.toml`
Closed this issue · 16 comments
I have a failure in PyO3 CI which I can also reproduce locally.
error: failed to download `serde v1.0.143`
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at `/Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.143/Cargo.toml`
Caused by:
feature `resolver` is required
Looking at the unpacked Cargo.toml it contains resolver = "1" - I wonder if the cargo package process has somehow added this and broken support for older cargo versions?
Encountered the same issue in one of my projects.
Considering that serde 1.0.142 still worked with rustc 1.48 and seeing that serde 1.0.143 does not, let's take a look at the changes between those two versions: v1.0.142...v1.0.143
There is no change that adds resolver = "1" to the manifest in the code, so I guess this is probably an issue with packaging process. 🤔
Looks like this is probably rust-lang/cargo#10954
According to that issue its not in stable, though? So presumably whoever does serde uploads needs to just bump the version and do a re-upload using stable cargo?
I followed up with @dtolnay on twitter DM about this, and his response was that there is no MSRV policy for serde, and thus this is an issue that is not likely to be fixed. I believe this issue can be closed.
Since serde's own metadata claims to support 1.13+, I'll leave this open until the next serde release is pushed. Should help community members who hit this in the meanwhile.
Yes, his comment to me, specifically, was:
the number in the readme is descriptive, not a policy; i'll update it
I followed up with @dtolnay on twitter DM about this, and his response was that there is no MSRV policy for serde, and thus this is an issue that is not likely to be fixed.
Hmm ... I find that a bit odd. 🤷 Sure, the readme could be argued about. But when even the cargo manifest shows something as rustc 1.13+, only to find out it actually requires something more like rustc 1.50+ when used in a project feels a bit like false advertising to me. So either the readme and manifest should be updated, or the crate should be rebuild with stable cargo which does not have that bug. There even is a dedicated CI job named msrv that tests with rustc 1.13. That does not feel like "there is no MSRV policy for serde" to me. 😕
I am aware that this may sound a bit harsh, especially considering that this issue is boils down to a bug in cargo and not in serde. So the serde developers are not even to blame for this. However, with such an important and widely used crate like serde this could potentially cause trouble for a lot of other projects that depend on serde. In my opinion, deciding not to fix this is not really helpful. So I am still hoping that one of the next serde releases comes with a fix for that - whether its just updating the MSRV or getting rid of that troublesome resolver line.
Where does the resolver = "1" line in the generated Cargo.toml come from, though? Cargo.toml.orig does not contain it. Seems like a bug in cargo package, doesn't it? Or is this because of the absent edition value?
In Suricata we try to support the Rust versions as they are shipped by the major (Linux) distributions, so Suricata can be packaged. For this reason we maintain a table of OS' that are important to us. Debian 11 (current stable) is the lowest, at Rust version 1.48. I think especially projects that are not pure Rust (like Suricata, which is C+Rust) care more about distro packaging and support, since we know our users do.
We're maintaining our table here: https://redmine.openinfosecfoundation.org/issues/4163 (screenshot added for reference)
I think would be great if Serde, and all other projects, would define a clear MSRV policy to help users of the crates ecosystem know what to expect.
Since there's a mismatch between rust-version in manifest and actual MSRV it could cause problems later if cargo becomes MSRV-aware and people start using it. It seems the best thing to do is to publish a new version with MSRV 1.13 and if serde MSRV is to be changed then do it in a single step involving update of the rust-version field. Also possibly yank 1.0.143.
error: failed to run custom build command for `substrate-runtime v2.0.0 (/Users/hamza/Applications/Documents/blockchain/substrate-git/substrate/runtime)`
Caused by:
process didn't exit successfully: `/Users/hamza/Applications/Documents/blockchain/substrate-git/substrate/target/debug/build/substrate-runtime-29670f71a495afb9/build-script-build` (exit code: 1)
--- stderr
Updating crates.io index
error: failed to download `serde v1.0.143`
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at `/Users/hamza/Applications/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.143/Cargo.toml`
Caused by:
feature `resolver` is required
consider adding `cargo-features = ["resolver"]` to the manifest
cargo 1.65.0-nightly (ce40690a5 2022-08-09)
code base : substrate 2.0.0
Having the same issue, i started getting from today, it was totally working fine couple of weeks back. I have used other versions of rust as well, but nothing was fruitful.
Command i'm using : cargo +nightly-2020-10-05 build
As said in #2259, the problem should be automatically resolved when the maintainer creates a new release using the nightly toolchain after nightly-2022-08-13 (tomorrow).
This has been fixed in 1.0.144: https://docs.rs/crate/serde/1.0.144/source/Cargo.toml
I'm still very confused as to the MSRV for serde. Should we be looking to rip serde out to get a consistent MSRV, or is the policy going to be made more clear? I admit I'm a bit confused why bother going to the hassle of making serde compile on rustc 1.1X if that's not going to be an MSRV.
This has been fixed in 1.0.144: https://docs.rs/crate/serde/1.0.144/source/Cargo.toml
Very good. :)
I'm still very confused as to the MSRV for serde. Should we be looking to rip serde out to get a consistent MSRV, or is the policy going to be made more clear?
I think the lesson here is that one can not really uphold a MSRV guarantee in one's own projects without pinning the dependencies down to exact versions via Cargo.lock, even if those dependencies have a certain MSRV themselves.
I think the lesson here is that one can not really uphold a MSRV guarantee in one's own projects without pinning the dependencies down to exact versions via Cargo.lock, even if those dependencies have a certain MSRV themselves.
This doesn't help libraries, only binary projects. Libraries which, themselves, wish to provide a concrete MSRV policy cannot do so without ensuring their dependencies meet the same MSRV policy. Up until today, as evidenced by the discussion on this bug, many downstream projects of serde provided an MSRV which clearly was not sustainable given serde's MSRV policy (or lack thereof). Hence my request for clarification.
The rust languages' attempt to work towards this was, at least in part, the rust-version field in Cargo.toml. Sadly it appears serde set this without actually "supporting" the rust-version in that field.