Crate grouping

[stifskere]

The problem

I believe there is too many crates that require a *_proc version for macros, or some libraries that are extensive that require a lot of self-made crates.

The problem now is that these crates need to be published separately, there is no clear way of publishing crates orderly or manage development dependencies.

The solution

This proposal might change a lot of things, but it doesn't make anything incompatible as the current way can still be kept so it shouldn't be a "breaking change".

If you have a cargo workspace, a main crate could be defined, that one being published in crates.io, and the other ones being "hoisted", with some sort of dependency requirement that is compatible with both development and release.

An example of what I'm thinking is this
./ is the root of the project in this example

./Cargo.toml

[workspace]
resolver = "3"
main = "main-crate"
dependencies = ["main-crate-proc", "some-other-crate"]

and inside the main-crate the dependencies could be imported such as

./main-crate/Cargo.toml

[dependencies]
main-crate-proc = { workspace = "main-crate-proc" }

And then in the upload process crates.io could "hoist" the dependencies, making them only accessible to that crate.

The crate data could or either be obtained from the main crate or be obtained from the workspace cargo.toml. with data I mean the author, tags and so on.

Other problems this also solves

Right now since the dependency crates are on crates.io like that you usually need to make read-me files that say "don't use this, use that crate, this is only a dependency", this could definitively be avoided that way.

This would also free up names, since the hoisted crates wouldn't be able to be downloaded manually, only trough the main crate.

Discussion opener

If it's necessary I could write a document explaining the whole implementation I have in mind. But I'd like to hear out the opinion of the people in this community.