Easy to mess up wrapper/proc-macro dependency relationship

[ultimaweapon]

Problem

I accidentally publish a crate that depend on an old version of macro crate due to everything working fine from a local repository. My main crate look like this:

[package]
name = "tsuki"
version = "0.3.1"
edition = "2024"

[dependencies]
tsuki-macros = { version = "0.1.0", path = "macros" }

This crate re-export macros from tsuki-macros. The problem is I added a new macro to tsuki-macros and bump its version then re-export it on tsuki but forgot to update the dependency version. This caused the following error for people who already have tsuki-macros in their cache while everything are working fine from the local repository:

error[E0432]: unresolved import `tsuki_macros::class`
   --> /home/ultimaweapon/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tsuki-0.3.1/src/lib.rs:310:9
    |
310 | pub use tsuki_macros::class;
    |         ^^^^^^^^^^^^^^^^^^^ no `class` in the root
    |

Proposed Solution

I propose that version should be optional when path is specified for a dependency during publish. In this case the version should be fetched from the dependency.

Notes

No response

[epage]

Your proposed solution is a duplicate of #11133 which was closed but you got there a different way which is worth talking about.

Proc-macros invert the dependency relationship because they usually generate code that depends on their wrapper library that depends on them.

The most immediate workaround is to use a = dependency (one of the rare times it won't cause problems).

When the wrapper is "big" enough (clap) or has functionality other deps can pull in without the macro (like serde_json depending on traits from serde), then it is best to split that out of the wrapper crate. At that point, the proc-macro can have a [target."cfg(false)".dependencies] on the new -core crate without = and it all works out.

rust-lang/rfcs#3826 proposes a new build-target in Cargo.toml to simplify the wrapper/proc-macro relationship. rust-lang/rfcs#3452 can also simplify it but has complexities that make it unlikely to happen.

[ultimaweapon]

Thanks for the information. Using = to specify the version is looking good. Is it possible to show a warning so people won't do the same mistake like this?

[epage]

The tricky thing about a warning is knowing when it is needed

• if you don't have any logic you call, then it is not needed
• if your logic is in the wrapper, then you needed it
• if you use internal api's, you need it
• if you use all public apis of the core package, you need a different structure

If the lint is allow by default, then the people who need it the most will be unlikely to override it. But because of false positives, it might not qualify to warn by default.

We should at least update The Little Book of Macros or other docs to talk about macro project structure.

[ultimaweapon]

I think putting this things in the docs does not help much (of cause it still good to have). My idea is showing this information along side the current error when people try to publish the crate that contains dependencies with path but without version. This error likely to be seen since usually people don't known they need to specify version for dependencies in the same workspace in order to publish (I was one of this).

[epage]

Yes, I recognize that documentation is a last ditch effort.

Interesting idea to provide guidance on that error message. If we move forward with #6153, then we could even turn it into an error on manifest parse if package.publish = true so you find out during development, rather than so late as publish time.