-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Command failing on crate json5
#24
Comments
From a cargo-minimal-versions perspective, this is working correctly. (cargo-minimal-versions detected the issues in json5's Cargo.toml.) json5's Cargo.toml specifies past = "2.0", pest_derive = "2.0" (which mean pase = ">= 2.0.0", pest_derive = ">= 2.0.0"), but in fact, an older version of past_derive cannot be compiled with the minimal version of its dependencies. As for the pest_derive requirement, it could be fixed by adding Additionally, the serde requirement in json5 also points to an older version (serde = "1.0", which means serde = ">= 1.0.0") that it cannot really compile.
As for the serde requirement, it could be fixed by adding I confirmed that it is now compiled by adding the following: [dependencies]
json5 = "0.4"
+pest_derive = "2.5.7"
+serde = "1.0.103" (Ideally, the json5's Cargo.toml should be updated, but this can also be addressed by specifying the appropriate dependency requirements on the user side.) |
How do you go about determining that from the failure? Is
Yes, but the crate no longer seems to be actively maintained so that's unlikely 😅 Ok so
For dependencies outside of the project that other crates are responsible for, min version changes need to be contributed upstream, or the project needs to additionally maintain the minimal version of implicit dependencies in
Determining dependency versions that are compatible at resolving within MSRVThis is probably due to my inexperience with this, so I've collapsed most of it but sharing in case it helps anyone else. Not sure if this is something Resolved (out of scope for `cargo-minimal-versions`)I manually ran
That error was also encountered with [dependencies]
serde = "1"
serde_derive = "1"
rust-ini = "0.18"
glob = "0.3"
temp-env = "0.2"
lazy_static = "1"
nom = "7"
float-cmp = "0.9"
futures = "0.3"
chrono = { version = "0.4", features = ["serde"] }
pathdiff = "0.2"
toml = "0.5"
yaml-rust = "0.4"
serde_json = "1"
indexmap = { version = "1.7", features = ["serde-1"] }
tokio = { version = "1", features = ["rt-multi-thread", "macros", "fs", "io-util", "time"] }
# Fails with any other dependency?
#notify ="4"
# None of these independently pass cargo-minimal-versions
#ron = "0.7"
#json5 = "0.4"
#reqwest = "0.11"
#warp = "=0.3.1"
#async-trait = "0.1" I was curious if [package]
name = "msrv-example"
version = "0.1.0"
edition = "2021"
[dependencies]
tokio = "1" # MSRV of config-rs in `0.13.x` releases:
$ cargo +1.56.1 check
Updating crates.io index
error: package `tokio v1.33.0` cannot be built because it requires rustc 1.63 or newer, while the currently active rustc version is 1.56.1
$ cargo minimal-versions check
info: running `rustup run nightly cargo update -Z minimal-versions`
Updating crates.io index
info: running `cargo hack check`
info: running `cargo check` on msrv-example (1/1)
$ grep -A1 'name = "tokio"' Cargo.lock
name = "tokio"
version = "1.0.1"
I'm aware of a separate project, A contributor at UPDATE: Seems I was after Resolved (`-Z msrv-policy` relies on Crates declaring `rust-version` to be reliable)
$ cargo +1.56.1 check
Updating crates.io index
error: failed to select a version for the requirement `memchr = "=2.6.0"`
candidate versions found which didn't match: 2.5.0, 2.4.1, 2.4.0, ...
location searched: crates.io index
required by package `object v0.31.1`
... which satisfies dependency `object = "=0.31.1"` of package `backtrace v0.3.68`
... which satisfies dependency `backtrace = "=0.3.68"` of package `tokio v1.29.1`
... which satisfies dependency `tokio = "=1.29.1"` of package `msrv-example v0.1.0 (/tmp)`
I can manually decrement until I get something compatible. I was just curious if there was tooling to help automate figuring out what those versions are 😅
That appears to be due to So like your earlier response, this approach works provided I ensure the lockfile (for CI MSRV checks) stays below
Resolved (`-Z msrv-policy` bumping incompatible implicit dependencies due to no compatible `rust-version` declared)The advice to add dependencies to $ cargo +nightly update -Z msrv-policy
Updating crates.io index
Updating ahash v0.4.8 -> v0.7.7
Updating dlv-list v0.2.3 -> v0.3.0
Updating hashbrown v0.9.1 -> v0.12.3
Adding once_cell v1.18.0
Updating ordered-multimap v0.4.0 -> v0.4.3
Removing ppv-lite86 v0.2.17
Removing rand v0.8.5
Removing rand_chacha v0.3.1
Removing rand_core v0.6.4
Adding version_check v0.9.4
$ cargo +1.56.1 check
Updating crates.io index
error: failed to select a version for the requirement `ahash = "=0.7.7"`
candidate versions found which didn't match: 0.4.8, 0.4.1, 0.4.0, ...
location searched: crates.io index
required by package `hashbrown v0.12.3`
... which satisfies dependency `hashbrown = "=0.12.3"` of package `ordered-multimap v0.4.3`
... which satisfies dependency `ordered-multimap = "=0.4.3"` of package `rust-ini v0.18.0`
... which satisfies dependency `rust-ini = "=0.18.0"` of package `msrv-example v0.1.0 (/tmp)` The
Problem this time was due to overriding the dependency chain partially, but since there wasn't a compatibility issue prior, I just needed to work in reverse instead reverting the |
Support for |
Fantastic! Thanks for that ❤️ Does My interest was just to verify that a library can build in CI while meeting it's stated MSRV / I suppose that can still happen with |
cargo-minimal-versions can be used to catch some issues that are missed when using -Zminimal-versions directly, such as dev-dependencies handling, path dependencies handling, and workspace handling. (See details section in readme for more) |
New to using
cargo-minimal-versions
, not sure if this is a bug or if I'm using it wrong.The
json5-rs
crate has not been updated since Sep 2021. On theconfig-rs
project this dependency was failing with errors in the reproduction output below related to some internal dependencies of the JSON5 crate.Reproduction
Output (click to expand)
If I run
cargo check
prior to this, it will work just fine. Afterwards acargo clean
will restore that, so it seems to be due to the downgrade / adjustments bycargo-minimal-versions
?Remove/Add/Downgrade output
Not sure why it removes the dependency and adds two different versions? The failures are happening from the lower version added?
The text was updated successfully, but these errors were encountered: