Crates with inter-dependencies

[tomaka]

I'm currently in the following situation:

• I have a crate named glium, and a crate named glium_macros
• glium is a dependency of glium_macros with a path source (glium_macros generates code that uses glium)
• glium_macros is a dev-dependency of glium with a path source (because the macros are used in the examples and the tests)

This system currently works (for example cargo test works), but I can't publish them.
If I try to publish glium, cargo complains that it can't find glium_macros. If I try to publish glium_macros, cargo complains that it can't find glium.

Even cargo publish --no-verify doesn't work.

[alexcrichton]

Hm this is unfortunate. We could modify the verification logic to ignore dev-dependencies, but this is in general where circular dependencies are... interesting!

[carols10cents]

I'm curious, do workspaces help this at all?

[alexcrichton]

Perhaps, yeah. For the circular case we'd just fundamentally need to either:

• Have a "batch publish"
• Disable checking dev-dependencies exist

For the former we could add cargo publish --all to work with workspaces and for the latter we'd just have to change crates.io

[lambda-fairy]

This issue could become more prominent with procedural macros 2.0, especially since the re-exporting macro pattern could increase the chances of a circular dependency sneaking in.

[Nemo157]

And now there's a discussion on users about this issue because of proc-macros.

I'm in favour of having a "batch publish" for workspaces, even just for non-circular dependencies it would save me having to work out what order I need to publish crates in.

One slight complication is that not every crate in the workspace might have changed. What I'd like in that case is for cargo to check that as part of the verification. For each crate, if the current version specified exists on the registry then pull down the existing package and compare it to the newly built package. If they differ print an error telling the user they need to bump the version of the non-matching crate. Don't perform the batch publish if any crate failed the comparison.

[carols10cents]

I think this is more of a cargo issue than a crates.io issue; I'm pretty sure the complaining is coming from cargo and not at all from crates.io.

So closing as a duplicate of rust-lang/cargo#1169 or as a duplicate of rust-lang/cargo#4242.