search

killercup / cargo-edit

A utility for managing cargo dependencies from the command line.
http://killercup.github.io/cargo-edit/
MIT License
3.01k stars 144 forks source link

[feature request] `set-version --workspace` for multiple workspaces #882

Closed bonsairobo closed 6 months ago

bonsairobo commented 6 months ago

When working in a git repo with multiple cargo workspaces, I currently need to run cargo set-version --workspace --bump minor in every workspace directory, and then go and manually fix all of the cross-workspace dependencies.

It would be awesome if the command could take care of the cross-workspace dependencies for me. I'd be willing to submit a PR with some guidance as I know nothing about this codebase yet.

epage commented 6 months ago

These commands are being written as-if they will be merged into cargo and follow the patterns of existing cargo commands and try not to innovate on cargo's design.

The most likely route for this within cargo's design is https://github.com/rust-lang/cargo/issues/5042

As this is out of scope, I'm closing. If there is a reason we should reconsider, let us know!

aevyrie commented 6 months ago

We are specifically not interested in nested workspaces. This is for a monorepo where each directory in the root is an independent workspace, but we actively don't want all of these directories to be analyzed at once, because the cost to do so would be prohibitive.

Consider a company with multiple large products, each which have hundreds of dependencies without much dependency crossover. Having all of these dependencies (potentially thousands) pulled in while you are working on just one of those products is a pretty terrible developer experience. However, there is some crossover in core libraries, and sometimes you need to bump versions across the entire repo.

I think this is a legitimate use of cargo at a larger scale, and something that nested workspaces won't address. Another pragmatic example of this is the recursive flag in cargo-sweep (unofficial, I know 🙂). It's not uncommon for users of cargo to store multiple independent workspaces/crates as siblings in their filesystem, and as projects get large, that can be a useful tool with tradeoffs compared to lumping everything into a single workspace, especially in a monorepo environment. Thanks for your consideration!