Do not require procedural macros to be published

[mulkieran]

The basic goal is not to have to publish procedural macros that are only used by their parent
crate and are not ever intended and would never be useful as a separate crate.

FIRST PROPOSAL:
Currently there are three dependency classifications:

• dependency

• build-dependency

• dev-dependency

• I would like to add a fourth, "compile-dependency". A dependency listed as a compile-dependency would be treated in the following way:

1. It would be made available at compile time, which is the same as for a "dependency".
2. The dependency location, if specified via a path, would be the actual location. That is, the rules that would translate it to an external crate for, e.g., the "cargo-package" command, would not hold as they would for a regular dependency.

SECOND PROPOSAL:
Relax whatever rule it is that requires the procedural macro to be defined in a separate crate and allow it to be
built merely as a submodule of its parent.

I think my first proposal is probably a great deal easier to do than the second.

This is loosely related to #1139

[ehuss]

Can you say more about why you would like to avoid needing to publish the proc-macro?

[mulkieran]

@ehuss Because it is purely support code for stratisd, and is not generally useful to any other crate in the whole world, so why publish? It'll just clutter up crates.io (I know there's plenty of clutter already). Also, since it's just support code there's a possibility that right after we release we'll realize we need to change it, and we'll get into a very busy cycle of releases to keep up with the changes to stratisd.

It was pointed out to me that there is a flaw in my proposal, though. The relative link to the procedural macro sub-package could actually refer to some source that is not in the source tree of the parent package. I think it would bother cargo developers generally to think that any code used in the project didn't have its source code included directly or transitively in a packaged crate. So, there would have to be a canonical place to unconditionally copy the source of the "compile-dependency" package, in case that source was located outside the source tree of the parent package.

[lambda-fairy]

This has been discussed before: https://internals.rust-lang.org/t/multiple-libraries-in-a-cargo-project/8259

Personally I don't think the added complexity is worth the effort.

[ehuss]

Thanks for the additional context. I appreciate that this can be awkward in some cases, but I recommend not worrying about cluttering crates.io. There are also tools available to help publishing multiple packages.

I'm going to close as this is a pretty massive change that I don't think can be handled via a GitHub issue. There's more context in the linked internals thread and rust-lang/rfcs#2224. Large features normally go through the RFC process where many of the details can be considered by the wider community.