CODEWITHSUNDEEP
rustrust-cargo
DennyHiu
DennyHiu

Reputation: 6130

Cargo package doesn't work with Rust's workspace?

I create a "workspace" with several folder within it following the tutorial I read here

It runs successfully with cargo run or cargo build

if all of the package were independent from each other, cargo package would run successfully. But as soon as one package depends on the other the cargo package will fail.

It displays: no matching package named "foo_2" found. location searched: registry "crates-io". Which is pretty weird, since I specifically add a local path on the dependencies.

Is this an intended behavior? if so, then why should I bother with workspace at all ?

The root Cargo.toml

[workspace]
members = [
    "foo_1",
    "foo_2",
]

foo_1/Cargo.toml

[package]
name = "foo_1"
version = "0.1.0"
edition = "2021"

# error here. It can't found the foo_2 package.
[dependencies] 
foo_2 = { path = "../foo_2", version = "0.1.0" }

foo_2/Cargo.toml

[package]
name = "foo_2"
version = "0.1.0"
edition = "2021"

[dependencies]

enter image description here

Error message:

PS E:\Works\Experimentals\rust-workspace> cargo package --workspace
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\foo_1)
   Verifying foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\foo_1)
    Updating crates.io index
error: failed to verify package tarball

Caused by:
  no matching package named `foo_2` found
  location searched: registry `crates-io`
  required by package `foo_1 v0.1.0 (E:\Works\Experimentals\rust-workspace\target\package\foo_1-0.1.0)`

Upvotes: 5

Views: 3657

Answers (1)

E_net4
E_net4

Reputation: 30082

Packaging and publishing crates requires all dependencies of said crate to also be available in a registry. For publishing this is relatively obvious, since consumers also need to be able to fetch and build transitive dependencies. Creating tarballs also happens to have the same constraints at the moment, so it is not possible if they are not meant to be published.

Whenever you have a project with many crates in a single workspace and wish to publish them on crates.io, you would start with the crate without dependencies and work your way up to the other crates.

cargo publish -p foo_2
cargo publish -p foo_1

Or, using cargo-workspaces:

cargo workspaces publish

Is this an intended behavior?

One can still publish crates in a workspace, so long as this is done in the right order. For packaging, it is a limitation at the time of writing. The current behavior could be linked with packaging being primarily part of publishing, so this could probably be improved.

If so, then why should I bother with workspace at all?

Tangential to the matter here. Workspaces exist mainly to settle other concerns, such as having a single source of compiled dependencies with a shared dependency lock. This distinction is described in that same link.

Upvotes: 4

Related Questions