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:
- verifies that all metadata is present (before building the code)
- checks all
path = "..."
dependencies and whether they are there - 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.
tags: #rust