I have found that using
cargo publish on a binary crate inside a workspace ignores the
Cargo.lock in the workspace directory, whereas
cargo build considers it. However, when moving the
Cargo.lock inside the binary crate root, both commands consider it.
To set up the environment:
mkdir foo # our workspace cd foo echo -e '[workspace]\nmembers = ["bar"]' > Cargo.toml cargo new bar # our binary cd bar cargo add beef@=0.5.0 cargo check # generate Cargo.lock with beef locked to 0.5.0 cargo add email@example.com # relax bounds cd ..
cargo build # uses beef 0.5.0 ✅ cargo publish --dry-run --allow-dirty -p bar # uses beef 0.5.2 (0.5.0 expected) ❌ cp Cargo.lock bar/ cargo publish --dry-run --allow-dirty -p bar # uses beef 0.5.0 ✅
cargo publish with
--locked does not change anything.)
Doesn't Cargo.lock in a workspace apply to all crates inside the workspace? To cite the Cargo book:
The key points of workspaces are:
- All packages share a common
Cargo.lockfile which resides in the workspace root.
Can I make
cargo publish consider my
Cargo.lock in the workspace root? Or what is the correct way to deal with this?
[EDIT]: I found that also
cargo package --allow-dirty -p bar does not use the workspace
Cargo.lock --- the
Cargo.lock in the produced crate makes a reference to
beef 0.5.2, not 0.5.0.
I believe that this means that crates published from workspaces, even when installed with
cargo install --locked, do not respect the workspace's
Cargo.lock. That sounds like a serious bug to me.