`az` version limit conflicts with next version of `embassy-rp`

[ericseppanen]

embedded-graphics contains an upper limit on the az version:

az = "~1.2.0"

This can conflict with other packages that require newer versions. For example, the current git code in embassy-rp contains a dependency on fixed 1.31.0, which requires az 1.3.

To reproduce:

cargo new --lib embedded-broken; cd embedded-broken
cargo add embassy-rp --git https://github.com/embassy-rs/embassy.git
cargo add embedded-graphics

error: failed to select a version for `az`.
    ... required by package `embedded-graphics v0.8.2`
    ... which satisfies dependency `embedded-graphics = "^0.8.2"` of package `embedded-broken v0.1.0 (/home/eric/work/rust/play/embedded-broken)`
versions that meet the requirements `~1.2.0` are: 1.2.1, 1.2.0

all possible versions conflict with previously selected packages

  previously selected package `az v1.3.0`
    ... which satisfies dependency `az = "^1.3"` of package `fixed v1.31.0`
    ... which satisfies dependency `fixed = "^1.31.0"` of package `embassy-rp v0.10.0 (https://github.com/embassy-rs/embassy.git#f21d63db)`
    ... which satisfies git dependency `embassy-rp` (locked to 0.10.0) of package `embedded-broken v0.1.0 (/home/eric/work/rust/play/embedded-broken)`

failed to select a version for `az` which could resolve this conflict

That change to embassy-rp hasn't been released yet, but when it is the conflict will affect anyone using both embassy-rp and embedded-graphics.

I'm not sure why az 1.3.x is not currently permitted by embedded-graphics (the limit was added in #809) , but it would make life easier if the upper limit could be removed so any semver-compatible az version would be allowed.

[ericseppanen]

I see from reading #806 that this was originally done to protect the msrv.

I understand that the goal was to protect people on old toolchains from hitting problems because az 1.3.0 contains rust-version = "1.85.0".

However, the advice from the Cargo Book is not to set upper limits:

Avoid constraining the upper bound of a version to be anything less than the next semver incompatible version (e.g. avoid ">=2.0, <2.4", "2.0.*", or ~2.0), as other packages in the dependency tree may require a newer version, leading to an unresolvable error ...

More specifically, the book says:

... it is not expected that the dependency specification excludes versions incompatible with your rust-version. In fact, supporting both allows you to balance the needs of users that support older Rust versions with those that don’t.

Does this add work for people on versions older that 1.84 (when the msrv-aware resolver arrived)? Yes, they're expected to manage Cargo.lock changes themselves, possibly by using rust 1.84+ to solve for the compatible dependency versions. (See also this setting). Note this strategy works even for projects with an msrv older than 1.84.

Adding work for those projects is still preferable to setting az = "~1.2.0", which causes unfixable errors when another dependency requires az 1.3.0. This problem will happen more frequently over time, as fewer people are on rust < 1.84 and more public crates update their dependencies.

[rfuest]

Changing the az dependency was a bad idea in hindsight. The next stable release of e-g will bump the MSRV to at least 1.84 to use the MSRV-aware resolver.

[ericseppanen]

Thanks for the response!

By "next stable release" do you mean 0.8.3 or 0.9.0?

It would be great to see an 0.8.3 release with the upper limit removed, so that existing projects will be unblocked immediately. That change alone doesn't require an MSRV bump, though it might add some friction to projects still on older cargo versions. If you're skeptical I can try to track down some more examples.

If you meant 0.9.0, then I worry this will continue to cause problems for a while, until all the library crates with an embedded-graphics ^0.8 dependency make the jump to the next version.