I'm hoping that this sparks some conversation about alternative solutions for Add named path bases to cargo (v2) by dpaoliello · Pull Request #3529 · rust-lang/rfcs · GitHub
From that RFC:
As a project grows in size, it becomes necessary to split it into smaller sub-projects, architected into layers with well-defined boundaries.
One way to enforce these boundaries is to use different Git repos (aka "multi-repo"). Cargo has good support for multi-repo projects using either
gitdependencies, or developers can use private registries if they want to explicitly publish code or need to preprocess their sub-projects (e.g., generating code) before they can be consumed.
If all of the code is kept in a single Git repo (aka "mono-repo"), then these boundaries must be enforced a different way: either leveraging tooling during the build to check layering, or requiring that sub-projects explicitly publish and consume from some intermediate directory. Cargo has poor support for mono-repos: the only viable mechanism is
pathdependencies, but these require relative paths (which makes refactoring and moving sub-projects very difficult) and don't work at all if the mono-repo requires publishing and consuming from an intermediate directory (as this may very per host, or per target being built).
The RFC proposes adding a "base" path table to Config.toml which can then be referenced by path dependencies in the Cargo.toml, thus allowing an external build system to setup the intermediates directory and Config.toml that points to it.
This approach has the advantage of being simple to implement and understand. A path dependency is the correct model for how Cargo should handle incremental builds and lock files for these types of dependencies.
The downside is that it does introduce yet another way to reference dependencies in Cargo (although it is a sub-variant of path dependencies) and adds another place where Cargo.toml depends on Config.toml.
Cargo supports directory sources which are intended to be created by
cargo vendor and have checksums for all crates: Source Replacement - The Cargo Book
One could imagine expanding support for these by creating an "externally managed" directory source without checksums or an index which can be referenced like a normal registry. Again, the external build system would need to generate a Config.toml with the registries that it will be setting up.
This has the advantage of being easy to understand but will require changes within Cargo to specially treat these registries like path dependencies for the purpose of incremental builds and lock files.
As suggested in https://github.com/rust-lang/cargo/issues/10789, if Cargo supported expanding environment variables within TOML files, then this could be done without any other changes to Cargo's TOML files.