You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose I have crates/foo and crates/bar in a monorepo. Whenever I bump the version of crates/foo, the content of Cargo.lock at the repo root also changes. That inevitably triggers rebuild of crates/bar and all of its deps, even if crates/bar does not depends on crates/foo and none of its files (except for the shared Cargo.lock) change.
Is there any way to avoid this?
The text was updated successfully, but these errors were encountered:
Currently we copy over the Cargo.lock completely untouched when creating the dummified sources (to build only dependency crates). When a workspace package's version changes, it gets recorded in the Cargo.lock and as you've observed it leads to a rebuild...
I don't think there is a (good?) way to avoid this besides adding an additional Cargo.lock file (i.e. workspace) for crates/bar and telling crane to build that workspace separately (crates/foo can still refer to crates/bar, but that workspace will also get rebuilt whenever crates/foo or crates/bar's versions change)
Implementing #288may be able to help with this (or rather it will avoid having to rebuild all of crates/bar's dependencies. Changing any version of a workspace package would still end up rebuilding the workspace crates even if all external deps aren't fwiw)
Suppose I have
crates/foo
andcrates/bar
in a monorepo. Whenever I bump the version ofcrates/foo
, the content ofCargo.lock
at the repo root also changes. That inevitably triggers rebuild ofcrates/bar
and all of its deps, even ifcrates/bar
does not depends oncrates/foo
and none of its files (except for the sharedCargo.lock
) change.Is there any way to avoid this?
The text was updated successfully, but these errors were encountered: