killercup / killercup/cargo-edit

Update `patch`ed local dependencies when running `set-version`

Open
#893 3 comments 0 reactions 0 assignees View on GitHub
cargo-set-version enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.