Managing dependencies of crates inside a workspace #3931
Comments
|
Ah yes currently this isn't possible I believe. You can use something like |
carols10cents
added
A-workspaces
|
I've got a similar use case, though I don't actually control the duplicated dependency, and I've got a bunch of them. The obvious solution, to me at least (and anyone who's worked on a large maven project), seemed to be some sort of variable substitution a la #4221, but it looks like that's a no-go. From that conversation:
Is anything of that sort in the works? My current (not very good) solution is to throw all external dependencies into a dedicated crate that then re-exports them so that they're at least all in one place. The downside is that now all of the external crates get built whenever any of my crates gets built, even if it needs only a subset, and it works poorly for macros, even with the accidentally-stabilized macro-reexport function. I've looked into cargo-outdated and cargo-edit, but both seem more concerned with making sure that things are up-to-date, when I really care more about making sure that all of my crates agree on dependency versions. |
|
Any update on this issue? Maybe something like managed dependency in maven is required to manage the version of some dependency throughout all sub-crates. |
|
+1 |
|
What about changing Cargo to allow specifying dependencies and their settings like version, etc., in workspace Cargo.toml? These could be used as default parameters for dependencies in inner crates. Workspace Cargo.toml could have default versions specified All inner crates could inherit version from workspace just by omiting version at all or specify any other dependency version for the crate |
Why? Can you explain please? 🙂 |
|
@sanmai-NL publication to crates.io forbids |
|
Any update on this? I have a similar issue to @MaikKlein and @jrobsonchase. I work on a project with 16 crates in a workspace and currently it's a pain to make sure we only have one version of each common dependency. It would be very useful to have a way to specify the versions once in the workspace |
I would prefer a more explicit syntax to communicate that the version is taken from a higher scope. This could be a new value for the version attribute such as |
|
For anyone interested in this issue I've posted an RFC which I think will help resolve this. Feedback on the RFC would be most welcome! |
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve kanidm#225
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. Remove cargo fmt check from CI because we have problems with different versions and fails continually. Instead, we use cargo-husky to ensure that all people run it automatically in its local, but this is not obligatory. Remove all versions between dependencies in internal packages. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve kanidm#225
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. Remove cargo fmt check from CI because we have problems with different versions and fails continually. Instead, we use cargo-husky to ensure that all people run it automatically in its local, but this is not obligatory. Remove all versions between dependencies in internal packages. Update to version 1.0.0-rc10, according to packages published. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve kanidm#225
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. Remove cargo fmt check from CI because we have problems with different versions and fails continually. Instead, we use cargo-husky to ensure that all people run it automatically in its local, but this is not obligatory. Remove all versions between dependencies in internal packages. Update to version 1.0.0-rc10, according to packages published. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve kanidm#225
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. Remove cargo fmt check from CI because we have problems with different versions and fails continually. Instead, we use cargo-husky to ensure that all people run it automatically in its local, but this is not obligatory. Update to version 1.0.0-rc10, according to packages published. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve kanidm#225
Add make entry to have all cargo versions updated from VERSION file. Add `tag_version` github action to update all cargo.toml and tag it and push it. Remove cargo fmt check from CI because we have problems with different versions and fails continually. Instead, we use cargo-husky to ensure that all people run it automatically in its local, but this is not obligatory. Update to version 1.0.0-rc10, according to packages published. In future cargo will support managing all dependencies from main Cargo.toml. Ref: rust-lang/cargo#3931 Resolve #225
|
This is called dependencyManagement in maven, it's a common feature of many build tools. |
|
Update for those landing here from a google search: @alexcrichton 's RFC (rust-lang/rfcs#2906) was accepted and the tracking issue #8664 has serious momentum and is close to complete. |
Workspace Foo
BarBarBarWhere
Baris an external dependency that I also maintain. When I want to update to a newer version ofBar, I would have to change 3 Cargo.toml files, which is a bit cumbersome. It would be nice if I could specify the dependency in one place. Is this possible?The text was updated successfully, but these errors were encountered: