# The pain releasing a multi-crate project

Today I released version 0.3.0 of my imag project, which contains over 30 sub-crates in the project repository.

This was pain in the ass (compared to how awesome the rust tooling is normally). Here I’ll explain why, hopefully triggering someone to make this whole process more enjoyable.

# There is no cargo publish --all

Yep, you’ve read that right. I had to manually cargo publish each crate individually. This is even worse as it sounds! One might expect that, the hacker I am, I wrote a short script a la each crate do cargo publish - but that’s not possible - because they depend on each other. I had to find the “lowest” in the stack and build from there.

And as cargo-graph does not yet support workspace projects, I could not even find out which one was the “lowest” crate in the stack (but I know my project, so that was not that much of an issue, actually).

Still, I had to run cargo publish on each crate by hand.

# Dependency-specs have to be re-written

As I depend on my own crates by path, I had to re-write all dependency specifications in my Cargo.toml files from something like

[dependencies.libimagstore]
path = "../libimagstore"


to something like

libimagstore = "0.3.0"


which is easily doable with vim and some macros, but still inconvenient.

# How it should be

How I’d like it to be: The cargo publish command should have a --all flag, which:

1. verifies that all metadata is present (before building the code)
2. checks all path = "..." dependencies and whether they are there
3. expects the user to provide some data on how to re-resolve the path dependencies, so dependencies are fetched from crates.io after publishing

and then automatically finds the lowest crate in the stack and starts building everything from there up to the most top-level crates and publishes them all in one go and only if all verification and building succeeded.