-
Notifications
You must be signed in to change notification settings - Fork 374
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
cargo-workspace
plugin cannot handle dependency cycles in dev-dependencies
#1662
Comments
Circular dependencies are problematic in several ways: - They result in cognitive overhead for developers, in trying to figure out what depends on what. - They present `cargo` with limits in what order the crates can be compiled in. - They invalidate build caches unnecessarily thus forcing `cargo` to rebuild certain crates. - They cause problems with tooling such as `release-please`. To actually break the circular dependencies, this patch inlines the uses of `development_transport` in the examples and tests for all sub-crates. This is only meant to be a short-term fix until #3111 and #2888 are fixed. To ensure we don't accidentally reintroduce this dependency, we add a basic CI that queries `cargo metadata` using `jq`. Resolves #3053. Fixes #3223. Related: #2918 (comment) Related: googleapis/release-please#1662
Sorry, for the super late response to this one. It looks like there's 2 issues:
|
Correct. We've resolved (1) on our end by getting rid of circular dependencies. That had other positive impacts. I think (2) is still an issue. Bumping a dev-dependency should not warrant a version bump because it is not user facing. |
I found a workaround by renaming dependencies: [dev-dependencies]
my-lib-dev = { path = "../my-lib", package = "my-lib" } Then you can The |
Circular dependencies are problematic in several ways: - They result in cognitive overhead for developers, in trying to figure out what depends on what. - They present `cargo` with limits in what order the crates can be compiled in. - They invalidate build caches unnecessarily thus forcing `cargo` to rebuild certain crates. - They cause problems with tooling such as `release-please`. To actually break the circular dependencies, this patch inlines the uses of `development_transport` in the examples and tests for all sub-crates. This is only meant to be a short-term fix until libp2p#3111 and libp2p#2888 are fixed. To ensure we don't accidentally reintroduce this dependency, we add a basic CI that queries `cargo metadata` using `jq`. Resolves libp2p#3053. Fixes libp2p#3223. Related: libp2p#2918 (comment) Related: googleapis/release-please#1662
Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.This is the client library for . We will only be able to assist with issues that pertain to the behaviors of this library. If the issue you're experiencing is due to the behavior of the product itself, please visit the Support page to reach the most relevant engineers.It is a library issue.
Please create an issue in the support console to ensure a timely response.If the support paths suggested above still do not result in a resolution, please provide the following details.
Environment details
release-please
version: 14.7.2Steps to reproduce
Cargo supports dependency cycles in the form of A -dep-> B -dev-dep-> A. In other words, I can have a crate A that depends on B but B can depend on A again in its
dev-dependencies
.release-please
doesn't seem to allow this which I think is an unnecessary restriction. Version bumping ofdev-dependencies
should not impact the version of a package so perhapsdev-dependencies
should just be ignored here: https://github.com/googleapis/release-please/blob/main/src/updaters/rust/common.ts#L71Making sure to follow these steps will guarantee the quickest resolution possible.
Thanks!
The text was updated successfully, but these errors were encountered: