-
Notifications
You must be signed in to change notification settings - Fork 37
build: setup msrv and edition consistently in all Cargo.toml #706
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
base: main
Are you sure you want to change the base?
Conversation
description = "Rust SDK to work with Superposition" | ||
edition = "2021" | ||
edition = { workspace = true } | ||
rust-version = { workspace = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if I am not wrong, this would get reverted in smithy generation
and I suppose we should use a different value just for the provider, so that we can have a higher inclusion percent
the server can be at a high MSRV like 1.82.0 but the sdk and the provider should not be dependent on this high of a number
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was based on @SanchithHegde's comment using the cargo msrv command (I think uniffi forces it). Running it currently. Will add the output to the PR.
Can we configure smithy to generate this the way we want it? cc: @ShubhranshuSanjeev @ShreyBana
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@knutties
smithy-build.json takes minimumSupportedRustVersion
as config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
➜ superposition git:(fix-msrv) ✗ cargo msrv verify --rust-version 1.81
[Meta] cargo-msrv 0.18.4
Compatibility Check #1: Rust 1.81.0
◝ Rust 1.81.0 Elapsed 2s ◞ Rust 1.81.0 Elapsed 3s ◡ Rust 1.81.0 Elapsed 3s ◜ Rust 1.81.0 Elapsed 4s [FAIL] Is incompatible
...
uniffi errors
One option is to skip uniffi in rust builds via feature flag (which is actually a good idea by @SanchithHegde). I will do this as well in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@knutties you would need to check the MSRV for the crate individually I guess
also, uniffi would be needed for the provider only (from the import point of view)
I was thinking something:
sdk and provider to have their respective MSRVs
and all other crates can use a common one from workspace (if at all a common MSRV is needed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - that is the plan. For crates that wider people have to use - we can lower the msrv - but we will need to remove uniffi dependency in Rust SDKs as it is not needed. uniffi is not needed for the Rust provider - it is needed only in the other language bindings.
We might need some additional CI checks to ensure we compile with some lower msrv as well. I will do that in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the rust sdk does not include uniffi
Problem
@SanchithHegde pointed out the missing
rust-version
andedition
values in our crates.Solution
Set the value in the top-level Cargo.toml and reference it in all the crates.