# Managing Internal Dependencies in Cargo Workspaces
## Introduction
In many Cargo workspaces, it's common to have multiple interdependent crates. However, when it comes to publishing a crate (like `cargo-e`) that depends on internal, unpublished crates (e.g., `e_crate_version_checker`), Cargo's publishing model poses significant challenges. This document explores the problem, discusses various workarounds, and debates possible improvements.
## Problem Statement
- **Workspace Internal Dependencies:**
Within a Cargo workspace, one crate may depend on another using a local path dependency. This setup works perfectly during development.
- **Publishing Challenges:**
When publishing to crates.io, Cargo strips out the local path attribute. As a result, every dependency must be versioned and available on crates.io. For internal crates marked with `publish = false` or not intended for publication, this leads to errors.
- **Desired Outcome:**
The goal is to publish the main crate (e.g., `cargo-e`) while still using internal crates without needing to publish them separately, thereby avoiding a cluttered registry.
## Current Workarounds
1. **Optional Dependencies via Feature Flags:**
Making the internal dependency optional so that the published version of the crate doesn’t require it by default.
2. **Code Embedding with `include!` or Build Scripts:**
Embedding internal code directly into the published crate. This works locally but often fails in restricted build environments (e.g., on crates.io build runners).
3. **Dedicated Internal Folder Structure:**
Proposing a top-level folder (e.g., `addendum`) to house standalone internal libraries or binaries. This approach aims to separate internal examples from the public API without breaking build rules.
## Discussion Points
- **Reproducibility vs. Flexibility:**
Cargo enforces reproducible builds by ensuring all dependencies are available from a public registry. This is crucial for end users but limits flexibility for developers who want to keep certain components internal.
- **Modularization Challenges:**
While embedding code or using optional dependencies might seem like a solution, these methods can complicate the build process and maintenance, especially as the project scales.
- **Community and Future Proposals:**
Given that this issue is common, engaging with the Rust community—via the Rust Community Discord or Rust Internals Forum—could lead to proposals for more flexible dependency management. An RFC might be a good next step to discuss how Cargo could better handle internal dependencies without forcing a publication.
## Conclusion
The tension between ensuring reliable, reproducible builds and enabling internal code reuse is a notable challenge in the current Cargo ecosystem. While the workarounds are viable, they come with trade-offs that might complicate long-term maintenance and usability. A broader community discussion could help shape improvements or even a formalized method for managing internal dependencies in Cargo workspaces.
## Next Steps
- **Engage with the Community:**
Join discussions on platforms like [Rust Community Discord](https://discord.gg/rust-lang) and the [Rust Internals Forum](https://internals.rust-lang.org/).
- **Draft a Proposal:**
Collaborate with other developers facing similar challenges to draft an RFC that could potentially influence future Cargo enhancements.
- **Document and Iterate:**
Use this document as a living record to gather feedback, iterate on potential solutions, and refine best practices for managing internal dependencies.
## User discussions
(https://users.rust-lang.org/t/referencing-workspace-member-as-dependency/86496) - use path, path doesn't work on the build runners, auto closed.
(https://internals.rust-lang.org/t/feature-discussion-allow-internal-dependencies-in-cargo/16445/4) user apologizes for spamming was auto closed - pointed to (https://github.com/rust-lang/rust/issues/44663).
(https://internals.rust-lang.org/t/publish-libraries-with-internal-dependencies/10843) this user was told they did something wrong by posting here, this question should be asked on the [https://users.rust-lang.org](https://users.rust-lang.org/) forum. This forum ([https://internals.rust-lang.org](https://internals.rust-lang.org/)) is dedicated to the development of Rust itself.