cargo package --workspace is not very useful · Issue #10948 · rust-lang/cargo (original) (raw)

Tracking

Unstable flag: -Zpackage-workspace

Stabilizing this would also close

• cargo publish multiple packages at once #1169

Testing instructions: #10948 (comment)

Implementation

• Package workspaces #13947
• Publish workspace #14433
• Support package selection options like --exclude in cargo publish #14659
  • When stabilizing, do a clean up of d30fde9 man page duplicates.

Changes since original plan

• Added--registry and --index flags to cargo package to know what registry will be used for generating the Cargo.lock file as if the internal dependencies were already published
• cargo publish is not atomic but it does verify all before publish

Open questions

• Are we ok with a slight compatibility breakage in cargo package? See cargo package --workspace is not very useful #10948 (comment)
• Are we ok stabilizing this and cargo publish multiple packages at once #1169 at the same time? Currently, they are behind the same flag
• What is the desired behavior for the publish timeout? Publish workspace #14433 uploads the crates in batches (depending on the dependency graph), and we only timeout if nothing in the batch is available within the timeout, deferring the rest to the next wait-for-publish. So for example, if you have packages a, b, c then we'll wait up to 60 seconds and if only a and b were ready in that time, we'll then wait another 60 seconds for c.
• What is the desired behavior when publishing some packages in a workspace that have publish = false? Publish workspace #14433 raises an error whenever any of the selected packages has publish = false, so it will error on cargo publish --workspace in a workspace with an unpublishable package. An alternative interface would implicitly exclude unpublishable packages in this case, but still error out if you explicitly select an unpublishable package with -p package-name (see -Zpackage-workspace is not smart about publish = false #14356). Publish workspace #14433 behavior is the most conservative one as it can change from an error to implicit excludes later.

Known issues

• "no hash listed" error with -Zpackage-workspace #14396
• Wrong workspace publication order in the presence of dev-dependencies #15412

Non-blocking issues

• cargo package (and hence cargo publish) verify step is slow from doing a full build #14941

Problem

Let's say you have a workspace

workspace/
  package_a/
    Cargo.toml (name="a", version="0.1.0")
  package_b/
    Cargo.toml (name="a", version="0.1.0", [dependencies] a="0.1.0")
  Cargo.toml (members = ["package_a","package_b"])

If you have already published a to crates.io, then cargo package --workspace will complete successfully.

Now, you update a to 0.1.1, and update b to use that new minimum version. If you try cargo package --workspace again, it will no longer work. You will get an error that 0.1.1 was not found.

This happens because cargo package makes a dummy package for your verification and it strips out all workspace and path information. This means it tries to retrieve the a 0.1.1 from the registry, which it fails to do.

Proposed Solution

If you have a workspace where some package b depends on another package a, where a is both specified by a version AND a path, AND that path is within the workspace members, then the following will happen:

cargo package --workspace

will make the new dummy project to verify the crates, but it will leave in the path information for a within b.

Notes

In my experience, I've never had a workspace where all crates are independent. There's always at least one that depends on another crate. When managing private registries, it's not uncommon to cargo package and upload the .crate file manually.

Currently, it's necessary to package each workspace member individually and upload them in the order they depend.

Ideally, we can run a single

cargo package --workspace

after bumping all versions, then get all of the .crate files and upload them in a batch.