Impossible to compile with `pyo3-stub-gen`

[Finomnis]

pyo3-stub-gen contains the following dependency:

quote = "1.0.41"

While serialport contains:

quote = ">=1, <=1.0.40"

This makes project containing both crates impossible to compile.

What's the point of <=1.0.40? If this breaks MSRV compatibility, that's the responsibility of the enduser's Cargo.lock file. It's dangerous to prevent newer versions of dependencies for several reasons, one among them being this very issue. Others are for example that you explicitely prevent bugfix updates of dependencies. That means, if the user is willed to bump their Rust version for the sake of getting a dependency bugfix update, you would actively prevent this.

If possible, I advise you to remove that restriction.

[RossSmyth]

the restriction is planned to be removed

[sirhcel]

What's the point of <=1.0.40? If this breaks MSRV compatibility, that's the responsibility of the enduser's Cargo.lock file. It's dangerous to prevent newer versions of dependencies for several reasons, one among them being this very issue. Others are for example that you explicitely prevent bugfix updates of dependencies. That means, if the user is willed to bump their Rust version for the sake of getting a dependency bugfix update, you would actively prevent this.

I put these restrictions into place because dependencies were breaking our MSRV with patch releases. This is an annoyance which i don't want do deliver to users of serialport-rs as there are people who can't just bump their Rust toolchain. I also see on the other hand that 1.59.0 is well aged and we need to progress, help with progressing #302 is welcome.

I don't see how a user can start with/create a lock file pinning such a dependency in the first place. How would you approach this?

[Finomnis]

@sirhcel Isn't that what cargo update --precise is for? So you can downgrade dependencies? Maybe I'm wrong.

I recently had to compile a hyper webserver with an old cargo version (being limited by our current yocto version) and I had to downgrade more than 20 dependencies for that, despite the actual hyper crate being still supported in msrv.

The idea is that once people successfully compile their package, the versions get saved in the Cargo.lock file, so things do not just break. If you then release an upgrade, the user can decide whether they upgrade the dependency as well or leave it as is. It's not your crate's responsibility to prevent MSRV breakages of dependencies.

I'd argue that the only true MSRV that should count is the Rust Version required to build a crate + all of its dependencies downgraded to the lowest version. That's exactly what I check here in one of my crates.

Although the entire MSRV topic is full of opinionated decisions, so I'm not entirely sure what the official guideline is.

Either way, the serialport crate is the first time I see a max version specified (without having some actual incompatibility), so I'm fairly certain that this is not really the best practice.

[sirhcel]

@sirhcel Isn't that what cargo update --precise is for? So you can downgrade dependencies? Maybe I'm wrong.

Yes, cargo update --precise can be used for that. I've seen this successfully in action in . I'm not going to argue that the crate's current MSRV ist pretty old (due to following what the latest Yocto LTS ships) and one of the goals of #302 is to bump our MSRV to 1.75 shipped by Scarthgap (which got released this year an I've been too busy to get the update done).

I recently had to compile a hyper webserver with an old cargo version (being limited by our current yocto version) and I had to downgrade more than 20 dependencies for that, despite the actual hyper crate being still supported in msrv.

The idea is that once people successfully compile their package, the versions get saved in the Cargo.lock file, so things do not just break. If you then release an upgrade, the user can decide whether they upgrade the dependency as well or leave it as is. It's not your crate's responsibility to prevent MSRV breakages of dependencies.

For existing builds - yes, Cargo.lock has you back. But what about starting from square one without an already existing Cargo.lock? This would require the user to figure out that a dependency needs to be downgraded and how to. On the other hand this happens from time time to time with a recent toolchain as well, like in your case. I don't think changing how we handle MSRV is the right thing for 4 releases. But it would be really great to make this better for the next major release.

I'd argue that the only true MSRV that should count is the Rust Version required to build a crate + all of its dependencies downgraded to the lowest version. That's exactly what I check here in one of my crates.

I don't see in the first place how this buys out the serialport crate. Doesn't cargo msrv juts return the MSRV specified in the crate's manifest? So 1.59.0 in our case here

serialport-rs$ cargo msrv show --output-format=minimal
1.59.0

and 1.85.0 for okio-graceful-shutdown. And debug/release building a clean checkout of serialport will fail with 1.59.0 without pinning dependencies through the crate manifest.

Although the entire MSRV topic is full of opinionated decisions, so I'm not entirely sure what the official guideline is.

Either way, the serialport crate is the first time I see a max version specified (without having some actual incompatibility), so I'm fairly certain that this is not really the best practice.

If you can give me a reference to best practice which would by us out of this dilemma, I would hapily go for it. I'm looking for one since quite a while.

I had a lot of conversations on this topic and it looks to me that there is no consensus whether the MSRV is a dimension of semver breakage or not. I'm inclined to say yes for the perspective of a fixed toolchain version. Cargo-semver-checks does not as it does not seem to care for MSRV. And Cargo's resolver takes the MSRV into account with Rust's 2024 edition - but we still have to wait here for the next Yocto LTS which will hopefully ship this Rust edition.

[Finomnis]

Hey, I didn't know Rust 2024's resolver takes MSRV into account! That's awesome. And yes you are right, there sadly isn't much consensus about this topic. I just know I can't use this crate with the python stubs generator, and I'm unsure who is to blame... I just feel like if they really do use features of the new version, then it's probably this crate. Because technically this crate is compatible with newer Rust versions, right? So I don't see why you would want the user to prevent upgrading, just to enforce the MSRV...

[sirhcel]

Would a Git dependency be fine for your use case @Finomnis? In this case we could create a branch with MSRV bumped and "dependency pinning" removed.

[Finomnis]

It's not that urgent, I currently simply use an old version of serialport which seems to work fine, I would just like to update to a new serialport version at some point.

[Finomnis]

This thread shows how crazy the MSRV situation actually is: https://www.reddit.com/r/rust/comments/1jmcv5v/a_rant_about_msrv/

Hopefully some guidance will be had at some point.

[Finomnis]

@sirhcel Any news? It seems this is also relevant for other people.

[Finomnis]

Ah, I just saw #307 (comment).

This bow wave of technical debt is breaking at the moment.

I'm sorry, take your time :) no rush.