foo_derive is using procedural macro (proc-macro = true) and its Cargo.toml has dev-dependencies to foo (to test whether the generated macros works)
foo_derive/Cargo.toml
[package]
name = "foo_derive"
version = "0.2.0"
authors = ["Boris <bgbahoue@gmail.com>"]
[lib]
name = "foo_derive"
proc-macro = true
[dev-dependencies]
foo = { path = "../foo", version = "0.2.0" }
The main foo package also has a dev-dependency to foo_derive to generate more easily the test code
foo/Cargo.toml
[package]
name = "foo"
version = "0.2.0"
authors = ["Boris <bgbahoue@gmail.com>"]
[dev-dependencies]
foo_derive = { path = "../foo_derive", version = "0.2.0" }
It all works fine until I try to package/publish any of these crates where I get the following error
error: failed to verify package tarball
Caused by:
no matching version `^0.2` found for package `foo_derive` (required by `foo`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.1.1, 0.1.0
Previous versions exists because previously I published the 0.1.0 version commenting out one of the dev-dependency, publish both crates, uncommented the dev-dependency and re-published the crates. Lot of manual changes and unneeded versioning; now that I have to push the next version, I'm wondering what is the best way to do that properly
@Gedweb Thanks for your reply. I tried to do that already but then my foo_derive tests don't compile.
Indeed, as part of the code generated by the #[derive()] procedural macro I need to use a few objects from foo crate and have to call extern-crate foo
If I remove the dev-dependency my tests fail to compile because the crate can't be found (rightfully so)
In the meantime I discovered the '--no-verify' option for cargo package or cargo publish but I'm not sure it's the way to do it properly
If I remember correctly --no-verify only tells your cargo to not verify before pushing to the server, crates.io then also does the same check server-side and will send back an error because of the missing dependency.
I don't know any easy workaround I'm completely happy with for this issue. One way to do it would be to add an unpublished foo_derive_test crate to your workspace that just contains the tests and depends on both crates via path links.
There's an existing issue on crates.io to allow this, it has the exact solution I was thinking of, which is allowing batch publishing of a workspace (I would love this even for non-circular dependencies, it's annoying having to list the correct order in which to publish, and not publish ones that haven't changed).
I agree adding an unpublished test crate would indeed allow to remove the dev-dependency and break the dependency circle, but it beats the logic of packaging tests & source code together no?
Manually changing it before publishing I guess. I happened to have rocket v0.2.7 in my cargo source folder (~/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.2.7) so took a look at its Cargo.toml (actually Cargo.toml.orig as cargo rewrites Cargo.toml during the upload):