cargo publish multiple packages at once

[alexcrichton]

It would be nice to have a flag to cargo publish which publishes all local packages in a DAG fashion.

Non-atomic publish was added in #14433, stabilization is being tracked in #10948

Testing instructions: #1169 (comment)

Notes (edit ehuss):

• publish multiple crates, races with dependencies #9507 would block this
• It would be nice if it supported atomic publishing.
• --dry-run should work correctly (will need to pretend that the previous crates have been published, maybe via patch?) See also Add a dry-run publish API crates.io#1515.
• See New publish API crates-io-cargo-teams#82 for other considerations for a new publish API to better accommodate this.

Blocking issues

Non-blocking issues

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

[wycats]

This would be awesome ;)

[huonw]

I suspect we may want to have a story with #883 if/when we implement this: I could easily imagine unintentionally publishing crates by not realising that I'm depending on them.

[botev]

Is there any progress on this? I think this would a very good thing to have. One of the nice things about crates is that they are modular, thus reduce the compile time of larger projects. However, if you are developing a large library compile times can get pretty slow (when it hits >2min I start to compile after 50% of the fixing, so it can compile while I'm fixing the other 50% of the issues). In this case you can split the library into sub-crates, where each sub-crate is in some sense standalone, or a build-up over "core" structure. However, each one of them would not make any sense on its own. Publishing each individually does not make any sense also and not packaging it together. If we can have this kind of publish --all this would give as an option to reduce compile times without any drawback from the user and publishing side of the library.

[matthiasbeyer]

Any updates whether this will be implemented and when?

[wycats]

@matthiasbeyer I think this fell through the cracks when we did workspaces. This issue was supposed to track wrapping --all up for publish but I guess it got lost since it was originally opened earlier?

@alexcrichton what's the status?

[alexcrichton]

@wycats AFAIK this has always been in the 'nice to have' category and hasn't progressed to the 'someone has put time into designing this' category.

[matthiasbeyer]

One thing I just thought about: When doing a workspace release, cargo should build everything and after everything is fine, publish all crates at once... if that is even possible. Not like "build & publish the first crate and continue for each crate" but rather "build everything, then publish everything".

[kpcyrd]

It seems that in a foo-rs, foo-rs/foo-sys project layout, you can't cargo package in foo-rs before foo-rs/foo-sys has been published.

[ufoscout]

I created a simple PR to deal with this annoying issue; it permits to execute cargo publish from a workspace.

One thing I just thought about: When doing a workspace release, cargo should build everything and after everything is fine, publish all crates at once... if that is even possible. Not like "build & publish the first crate and continue for each crate" but rather "build everything, then publish everything".

Unluckily I did not find a way to implement this logic because cargo requires that all the dependencies of a package are in the repository or the package phase (when the tarball is created) fails; consequently, before publishing a package with a "path" dependency, that dependency must be in the repository.

[Nemo157]

Something else I would want that I don’t think that can handle is only publishing updated packages, if one of the packages already exists at its current version number it should be downloaded and verified that the new package is identical.

[softprops]

being new to workspaces but not to cargo this feels very much like a paper cut. My finger just got nipped when I tried to publish a new workspace project by following the docs

...then realized that order matters. The validation of packages will fail of one of the workspace packages depends on another in the same release but which may not have been published first. In my case it's a very simple ordering but for those new to cargo, something like cargo publish --all could get the ordering right without putting a burden on me at all. Something like that would be a much nicer new user experience, also a much nicer convenience to those that have learned the ordering semantics for the more more manual publishing approach.

[matthiasbeyer]

It would definitively help me with imag where I publish over 50 crates in one release!

[softprops]

https://github.com/Byron/google-apis-rs and https://github.com/rusoto/rusoto would also like benefit greatly from this

[torkleyy]

This sounds useful, but I'm wondering what the exact behaviour should be. What if you have a path dependency and there's no version specified, should Cargo modify the Cargo.toml for that?

[mitchmindtree]

@torkleyy interesting point. It probably should not modify the Cargo.toml at all, but it would be worth considering whether or not cargo should allow for path dependencies but only for crates within the same workspace.

E.g. If building foo and a dependency on bar is specified via a path, perhaps cargo could implicitly publish the new version of foo with the version of bar that was published during the same cargo publish --all? This would also allow for cargo to easily build everything first locally before publishing any of the packages.

Simplified Steps

I'm imagining cargo publish --all should do something like the following:

1. Check manifests and version validity of all packages before starting to build any.
2. Create DAG of workspace packages and determine the build order.
3. Build packages. If any failures occur, bail out of the whole process.
4. If all manifests and valid and packages are built, publish all packages in the order in which they were built.

It would be worth considerinng if step 4 should be a special "atomic step" recognised by crates.io so that if for some reason the net drops out or there's a crash the user doesn't end up with only half of their packages published.

[Nemo157]

@mitchmindtree I would like to also see an extra step between 3 and 4 doing full workspace package validation to replace the current pre-publish validation. This does the normal per-package validation steps with 2 changes:

1. crates.io is queried for an exact version match of any of the crates. If there is an exact version match then the contents are compared to make sure the crate hasn't changed, if they match the crate is removed from the set to publish. (Basically making publishing a crate idempotent so that you can republish a workspace where you have only updated some of the crates.)

2. during this validation crates can depend on crates that are either available on crates.io or are part of the current set to publish.

[torkleyy]

I started working on this here: https://gitlab.com/torkleyy/cargo-publish-all

[epage]

Was hoping to do a call for testing but ran into #14721 which breaks some ways of testing this feature.

[foresterre]

Are there ways of testing which can already help?

I would absolutely love to have this feature built in.

[epage]

Feel free to give it a try in nightly. You don't need more formalized testing instructions to give it a try.

[epage]

Tried to test it again and ran into another issues, see #14789

[nyurik]

UPDATE
The issue bellow is solvable with the nightly toolchain: cargo +nightly -Z package-workspace publish --dry-run -- which handles the unpublished version.

Original post

I ran into a related issue: my workspace has 3 packages that are chain-dependent (varnish -> macros -> sys). The version is the same for all of them, and gets updated at the same time. All 3 packages' Cargo.toml use version.workspace = true, and in their dependencies use the needed varnish-*.workspace = true . The workspace one looks like this:

[workspace.package]
version = "0.2.2"

[workspace.dependencies]
varnish = { path = "./varnish", version = "0.2.2" }
varnish-macros = { path = "./varnish-macros", version = "0.2.2" }
varnish-sys = { path = "./varnish-sys", version = "0.2.2" }

cargo publish --dry-run fails due to failed to select a version for the requirement because the sub-package hasn't been published yet -- because 0.2.2 has not been published yet.

[epage]

Call for testing

cargo publish --workspace is now available and we're looking for feedback to see if this can be stabilized!

Basic steps:

Requirements:

• 1.85.0-nightly (2024-12-01) or newer

Try cargo publish -Zpackage-workspace in your existing workflows and with various combinations of multiple packages being selected (--workspace, --exclude, -p foo -p bar)

Support in third-party release tools:

• cargo release v0.25.14 as cargo +nightly release -Zworkspace-publish

In particular, consider

• Publish order is correct?
• Handling of cycles?
• Correctly waiting between published packages?
• --dry-run works?

Note:

• You are still subject to crates.io rate limits and publish may fail in the middle of a workspace, see When crates.io gives 429, cargo should back off and retry later #13530

Please leave feedback on this issue

[marc2332]

hey @epage ! Just tried it to release freya v0.3.0-rc.0 and it seems to have worked perfectly!

• Publish order is correct
• (I don't know what cycles are) Handling of cycles
• Correctly waiting between published packages?
• --dry-run works

Here is the command I ran (with and without --dry-run):

cargo +nightly publish --features skia-engine --workspace -Z package-workspace --exclude "examples" --exclude "freya-installer-example"

Love this, I hope it gets stabilized soon! ✨ 🦀

[kpreid]

I just tried out the feature with cargo 1.85.0-nightly (d73d2caf9 2024-12-31). All the feedback I can think of:

• Once I got it correctly invoked, it worked fine.
• I really appreciate that the verification step now verifies all packages before any of them are published. That’s the one thing I could not do just by scripting multiple cargo publish commands.
• It was an unpleasant surprise that cargo publish --workspace does not automatically skip package.publish = false packages (like my xtask and heavy integration tests), but aborts instead. I can see why doing so automatically might be worse (e.g. someone forgot to write package.publish = false), but I think there should be an option which means “exclude all publish = false”, for those workspaces where that is the correct choice. (Or, more foolproof, require every package to specify some publish value first?)
  • (workspace.default-members is not an appropriate solution here because that would stop tests in the unpublished packages from running by default.)
• Cargo printed “You may press ctrl-c to skip waiting; the crate should be available shortly.” as it usually does. I wonder what this does to publishing multiple packages — surely it must either cancel the remaining packages, run the risk of erroring out due to not waiting before publishing the next package, or do nothing. Perhaps this message should not be printed in this case. Perhaps a different message should be printed while it waits (or at other times too), indicating the number of packages remaining to be published.
• I worry about the situation where uploading fails halfway through. Would I have to specify exactly the packages not already published when trying again, or would cargo be able to DWIM and publish only the missing ones?
• During the packaging step, it printed Updating crates.io index for every package. This seems like unnecessary extra traffic to crates.io; a drop in the bucket for crates.io itself but it could be bad for a user on a high-latency network trying to publish many packages.
• The call for testing has the wrong feature name (-Zpublish-workspace, not -Zpublic-dependency).

[weihanglo]

does not automatically skip package.publish = false packages (like my xtask and heavy integration tests)

IMO this is a bug. You cannot even publish a single crate with publish = false.

I worry about the situation where uploading fails halfway through. Would I have to specify exactly the packages not already published when trying again, or would cargo be able to DWIM and publish only the missing ones?

#13397 might be related

During the packaging step, it printed Updating crates.io index for every package. This seems like unnecessary extra traffic to crates.io

This is likely because Caarg were building a lockfile for each package. I am aware of it, and think it should be fixed. Currently specifying --offline helps (of course you need to fetch all dependencies upfront).

[marc2332]

I was surprised as well that it didn't skip those crates with publish = false, hence why I used --exclude in my command.

[epage]

@kpreid

It was an unpleasant surprise that cargo publish --workspace does not automatically skip package.publish = false packages (like my xtask and heavy integration tests), but aborts instead. I can see why doing so automatically might be worse (e.g. someone forgot to write package.publish = false), but I think there should be an option which means “exclude all publish = false”, for those workspaces where that is the correct choice. (Or, more foolproof, require every package to specify some publish value first?)

@weihanglo

IMO this is a bug. You cannot even publish a single crate with publish = false.

cargo publish -p publish-disabled will error out, rather than skip the package. If we automatically skip packages, we'd need to decide in what circumstances we skip vs error and why.

[epage]

@kpreid

Cargo printed “You may press ctrl-c to skip waiting; the crate should be available shortly.” as it usually does. I wonder what this does to publishing multiple packages — surely it must either cancel the remaining packages, run the risk of erroring out due to not waiting before publishing the next package, or do nothing. Perhaps this message should not be printed in this case. Perhaps a different message should be printed while it waits (or at other times too), indicating the number of packages remaining to be published.

Might be good to open an issue for this.

[epage]

During the packaging step, it printed Updating crates.io index for every package. This seems like unnecessary extra traffic to crates.io

This is likely because Caarg were building a lockfile for each package. I am aware of it, and think it should be fixed. Currently specifying --offline helps (of course you need to fetch all dependencies upfront).

This comes about from an implementation detail. We are effectively stringing together separate commands (package, build). Each command loads the registry's index separately. Each will see that it hasn't yet checked if there is a newer version of the index available and will check.

We could fake it by overriding the config to be in offline mode but we don't have an easy way to layer that on top of the existing config, so we'd be mutating the config and, ideally, trying to roll back without being able to use RAII because we'd need to have a &mut while we share that with other commands.

I thought we had an issue about checking the registry less often in general but I can't find it (if lockfile didn't change and everything is cached locally, why check?).

[weihanglo]

cargo publish -p publish-disabled will error out, rather than skip the package. If we automatically skip packages, we'd need to decide in what circumstances we skip vs error and why.

True. Sorry I didn't think that hard. Also need to consider consistency between cargo package and cargo publish, where the former may not really care about package.publish

[epage]

I just ran into a failure doing a dry-run publish that I'm still trying to characterize.

This is on https://github.com/crate-ci/typos

$ cargo +nightly publish --workspace --dry-run --exclude codespell-dict --exclude wikipedia-dict -Zpackage-workspace
...
   Verifying typos-dict v0.12.1 (/home/epage/src/personal/typos/crates/typos-dict)
error: failed to verify package tarball

Caused by:
  checksum for `varcon v1.0.1` changed between lock files

  this could be indicative of a few possible errors:

      * the lock file is corrupt
      * a replacement source in use (e.g., a mirror) returned a different checksum
      * the source itself may be corrupt in one way or another

  unable to verify that `varcon v1.0.1` is the same as when the lockfile was generated

This reproduces when I drop down to cargo package

$ cargo +nightly package --workspace -Zpackage-workspace

I thought it was because I had a local edit but that isn't true. I just checked and varcon does not have any changes since the last release.

If I do these dry-runs on other repos, like clap, I don't have any problems like this.

UPDATE

the packaged typos-dict lockfile has

[[package]]
name = "varcon"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e9146d8774c298fff5715399e91d8495fe262198d3532b529cb73787b284b89d"
dependencies = [
 "varcon-core",
]

Creating a lockfile independent of any of this, I get

[[package]]
name = "varcon"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e9146d8774c298fff5715399e91d8495fe262198d3532b529cb73787b284b89d"
dependencies = [
 "varcon-core",
]

UPDATE

I looked closer at clap and clap_complete has clap=4.5.22 in the lockfile, despite packaging clap=4.5.23. I tried forcing the version req to 4.5.23 but I'm getting other errors

error: failed to prepare local package for uploading

Caused by:
  failed to select a version for `clap_lex`.
      ... required by package `clap_builder v4.5.23`
      ... which satisfies dependency `clap_builder = "=4.5.23"` of package `clap v4.5.23`
      ... which satisfies dependency `clap = "^4.5.23"` of package `clap_complete v4.5.40 (/home/epage/src/
personal/clap/clap_complete)`
  versions that meet the requirements `^0.7.4` are: 0.7.4

  all possible versions conflict with previously selected packages.

    previously selected package `clap_lex v0.7.1`
      ... which satisfies dependency `clap_lex = "^0.7.0"` (locked to 0.7.1) of package `clap_complete v4.5
.40 (/home/epage/src/personal/clap/clap_complete)`

  failed to select a version for `clap_lex` which could resolve this conflict

UPDATE

I'm thinking that the clap_lex problem is what is causing an older clap to be used.

My guess as to what is happening is that we are using the committed Cargo.lock as a starting point

[kpreid]

Might be good to open an issue for this.

Done: #15005

If we automatically skip packages, we'd need to decide in what circumstances we skip vs error and why.

I don't think it has be automatic, and to minimize the chance of proceeding with a user error, it shouldn’t be. Instead — actually, this is a nontrivial design space and so I filed a separate issue for it, #15006.

[elmarco]

hey @epage ! I tried it on my usbredir binding crates, and it fails to resolve a member/ffi dependency. You should be able to reproduce with https://gitlab.freedesktop.org/elmarco/usbredir-rs.git (I used cargo +nightly publish -Zpackage-workspace --workspace --dry-run). thanks!