-
Notifications
You must be signed in to change notification settings - Fork 151
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
Update patch
ed local dependencies when running set-version
#893
Comments
set-version
in workspace does not update dependencies when using workspace level patch patch
ed local dependencies when running set-version
There are two approaches we can take with this command:
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
On the other hand, one could say that the users intent is clear so we should support it either way. Any thoughts? |
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 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 |
You can run |
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
andmy_bin
depending onlib_foo
, thenmy_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:
my_bin
, define the dependency aslib_foo = {version = "0.1.0", path = "../lib_foo"}
.patch.crates-io.lib_foo = {path = "./lib_foo"}
, then insidemy_bin
use a regular dependencylib_foo = "0.1.0"
The second style has the benefit that once a release is published to
crates.io
, thenmy_bin
can be zipped and sent to be executed outside of the workspace without any changes (and without having to includelib_foo
in the archive). This property is pretty useful.Issue
If I run
cargo set-version
in the workspace described above, both crateslib_foo
andmy_bin
are updated to0.2.0
. However, the dependency requirement is only updated when using the first method (it becomeslib_foo = {version = "0.2.0", path = "../lib_foo"}
). When using the second method (workspace level patch), the dependency requirement remainslib_foo = "0.1.0"
. The expected behavior is forcargo set-version
to set it tolib_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. Runningcargo set-version 0.2.0
exhibits the issue.The text was updated successfully, but these errors were encountered: