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

[demurgos]

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.

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.

[epage]

There are two approaches we can take with this command:

• support everything people want
• align with cargo as well as possible.

If our aim is to eventually be merged into cargo (which no one has requested atm), then the former is a bit more painful as we then have to rip out all of that functionality.

So far, the cargo workflows seem to focus on the first workflow

• Limiting oneself to zipping up a package to share it means you don't have access to very helpful features like workspace inheritance
• cargo add adds path dependencies, rather than patches, and doesn't really interact with the patches

On the other hand, one could say that the users intent is clear so we should support it either way.

Any thoughts?

[demurgos]

To provide more context, the reason why I want to be able to avoid depending on workspace features directly inside the crate is that this particular crate is used to build a Node native module and is distributed through npm instead of crates.io. When working locally, I would like to build the native extension using the crates from the workspace, but when I do a release and publish it, I want the npm package to be able to build the native module if no pre-built version is available.

Another way to solve my use case would be to have a way to "eject" a manifest from the project: get access to the manifest generated by cargo when publishing. I don't think it's currently possible, but maybe it is.

The solution for my issue was to write an xtask command to handle upgrades with custom code. This also let's me bundle a dedicated lock file. I still feel that handling locally patched crates may be a nice feature, but I also understand that you need to a strike a balance between bloat and actually needed features. Because of the custom script, this is not a blocker for me; but maybe other people may also have feedback about the usefulness of this feature for their use-cases.

[epage]

Another way to solve my use case would be to have a way to "eject" a manifest from the project: get access to the manifest generated by cargo when publishing. I don't think it's currently possible, but maybe it is.

You can run cargo package.