-
Notifications
You must be signed in to change notification settings - Fork 153
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
Use workspace versioning and relax hashbrown
/indexmap
deps
#956
Use workspace versioning and relax hashbrown
/indexmap
deps
#956
Conversation
This commit does two things: first, switch a lot of metadata-definition to use the workspace-package inheritance allowed since Rust 1.64 (including several shared dependencies); second, relax the installation requirements on `indexmap` and `hashbrown` to allow both to use their most recent two majors. Dependents can then install `rustworkx-core` using either (say) `hashbrown 0.13.2` or `hashbrown 0.14.0` as desired, and similar between `indexmap 1.9.3` and `indexmap 2.0.0`. This commit leaves the lock file in the `hashbrown 0.14.0`, `indexmap 2.0.0` state, although note that some other crate dependents still use `hashbrown 0.12.3` internally, but this doesn't matter for the public API surface. I tested it manually in the `hashbrown 0.13.2`, `indexmap 1.9.3` state by updating those two dependencies with: cargo update -p '[email protected]' --precise 1.9.3 cargo update -p '[email protected]' --precise 0.13.2 cargo update -p '[email protected]'
It's probably possible to avoid allowing multiple versions of |
Last comment: I left the |
This is a good reminder that I forgot to forward port #929 to main. I did that on stable first for the 0.13.0 bugfix release and the msrv version constraint is lower on 0.13.x so we needed a wider hashmap range. |
Hahahaha, that's funny - I guess you can just close this PR if it's already done, then. |
Nah this pr is good, we need the fix on main too and this does it combined with more modern workspace usage. |
Pull Request Test Coverage Report for Build 5787373908
💛 - Coveralls |
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.
LGTM, this will simplify keeping the dependencies between rustworkx and rustworkx-core consistent in the futre
…t#956) This commit does two things: first, switch a lot of metadata-definition to use the workspace-package inheritance allowed since Rust 1.64 (including several shared dependencies); second, relax the installation requirements on `indexmap` and `hashbrown` to allow both to use their most recent two majors. Dependents can then install `rustworkx-core` using either (say) `hashbrown 0.13.2` or `hashbrown 0.14.0` as desired, and similar between `indexmap 1.9.3` and `indexmap 2.0.0`. This commit leaves the lock file in the `hashbrown 0.14.0`, `indexmap 2.0.0` state, although note that some other crate dependents still use `hashbrown 0.12.3` internally, but this doesn't matter for the public API surface. I tested it manually in the `hashbrown 0.13.2`, `indexmap 1.9.3` state by updating those two dependencies with: cargo update -p '[email protected]' --precise 1.9.3 cargo update -p '[email protected]' --precise 0.13.2 cargo update -p '[email protected]' Co-authored-by: Ivan Carvalho <[email protected]>
This commit does two things: first, switch a lot of metadata-definition to use the workspace-package inheritance allowed since Rust 1.64 (including several shared dependencies); second, relax the installation requirements on
indexmap
andhashbrown
to allow both to use their most recent two majors. Dependents can then installrustworkx-core
using either (say)hashbrown 0.13.2
orhashbrown 0.14.0
as desired, and similar betweenindexmap 1.9.3
andindexmap 2.0.0
.This commit leaves the lock file in the
hashbrown 0.14.0
,indexmap 2.0.0
state, although note that some other crate dependents still usehashbrown 0.12.3
internally, but this doesn't matter for the public API surface. I tested it manually in thehashbrown 0.13.2
,indexmap 1.9.3
state by updating those two dependencies with:This commit is kind of a proof-of-concept. I'm happy to split the different parts of it into a couple of different commits / PRs if preferred. I only did all the workspace stuff because it was more convenient for me when playing with the versions of packages - I'm totally happy to close this PR and reopen it in a couple of different bits.
Using this, I was able to build Qiskit against
rustworkx-core =0.14.0
using bothhashbrown 0.13.2
andhashbrown 0.14.0
with a couple of suitablecargo update
commands.Taken verbatim, this PR fixes #911 - it doesn't replace
hashbrown
, but it does relax the version requirements.