killercup / killercup/cargo-edit
Update `patch`ed local dependencies when running `set-version`
- Dominant language
- Rust
- Stars
- 3.5k
- Forks
- 166
- PR merge metrics
- No merged PRs in 30d
Description
# Context
I have a Cargo workspace with multiple members. Inside my workspace, crates should depend on each other. So if my workspace contains both `lib_foo` and `my_bin` depending on `lib_foo`, then `my_bin` should always use the version from the repository when working locally (`cargo run`, `cargo test`, etc.).
I know of two ways to achieve this:
1. In `my_bin`, define the dependency as `lib_foo = {version = "0.1.0", path = "../lib_foo"}`.
2. At the workspace level, define `patch.crates-io.lib_foo = {path = "./lib_foo"}`, then inside `my_bin` use a regular dependency `lib_foo = "0.1.0"`
The second style has the benefit that once a release is published to `crates.io`, then `my_bin` can be zipped and sent to be executed outside of the workspace without any changes (and without having to include `lib_foo` in the archive). This property is pretty useful.
# Issue
If I run `cargo set-version` in the workspace described above, both crates `lib_foo` and `my_bin` are updated to `0.2.0`. However, the dependency requirement is only updated when using the first method (it becomes `lib_foo = {version = "0.2.0", path = "../lib_foo"}`). When using the second method (workspace level patch), the dependency requirement remains `lib_foo = "0.1.0"`. The expected behavior is for `cargo set-version` to set it to `lib_foo = "0.2.0"`.
In general, if a crate has a workspace-internal dependency before `cargo set-version`, then this dependency should be updated accordingly.
# Reproduction
I created [a repository with reproduction instructions](https://github.com/demurgos/cargo-set-version-repro).
There is one binary crate in `./bin` and two library crates `./eternaltwin_config` and `./eternaltwin_core` (I had to reuse the name of one of my libs so crates-io patching works). The dependency on `./eternaltwin_config` uses the first method, the dependency on `./eternaltwin_core` uses the second method. Running `cargo set-version 0.2.0` exhibits the issue.
Contributor guide
Research direction
Start with the `cargo set-version` entry point and reproduce the behavior using the workspace described in `./bin`, `./eternaltwin_config`, and `./eternaltwin_core`, including the workspace-level `patch.crates-io` dependency. Trace how internal dependency requirements are selected during version updates and add regression coverage for the patched dependency. Done means both dependency styles update to `0.2.0` when running `cargo set-version 0.2.0`.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100