Support multiple crates in a .crate file

[nrc]

For example, allow path dependences to be added to the .crate file or allow published crates to depend on a GitHub repo.

[huonw]

The path dependencies are handled by publishing them separately, e.g. foo can depend on bar = { path = "bar", version = "0.1" }, which will get automatically rewritten to a bar = "0.1" dependency when published.

Depending on external resources is against crates.io's philosophy: crates.io tries to ensure that it contains everything it needs to build, and depending on a random external URL will suffer from e.g. link-rot.

[nrc]

For path deps, I am proposing that an alternative, additional publication style should be supported where they are combined into the .crate file.

[alexcrichton]

Would a different title for this issue perhaps be "support more than one crate in a .crate file"? @huonw is right in that not relying on unpublished crates is a feature of crates.io (rather than a bug) to ensure everything builds, and that's the same reason that git dependencies aren't allowed. One of the nice aspects of crates.io are the reproducible builds, but that does have some limitations!

Architecturally it would be quite difficult to support more than one crate in a .crate file I think, but not necessarily impossible.

[thepowersgang]

I'd like to note my support for multiple crates per "package" - Mostly to prevent the proliferation (and management overhead) of helper-only crates. See https://crates.io/crates/va_list-test/

[dwijnand]

Looks similar to boats' idea in https://internals.rust-lang.org/t/multiple-libraries-in-a-cargo-project/8259.

[epage]

See also https://github.com/rust-lang/rfcs/pull/3452

[epage]

Also, another prior thread on this: https://users.rust-lang.org/t/publish-crate-without-publishing-local-sub-crates/11299