Cargo: Optional Version For Path Dependencies On Publish?

Hey everyone! Let's dive into a proposal that could smooth out some rough edges when publishing Rust crates that rely on local dependencies. We're talking about a situation where specifying the version field could become optional when you're pointing to a dependency using the path attribute in your Cargo.toml.

The Problem: Accidentally Publishing with Outdated Local Dependencies

So, here's the scenario: Imagine you're working on a crate, let's call it tsuki. This crate depends on another crate you're actively developing locally, say tsuki-macros. You've got your Cargo.toml set up like this:

[package]
name = "tsuki"
version = "0.3.1"
edition = "2024"

[dependencies]
tsuki-macros = { version = "0.1.0", path = "macros" }

Now, things get tricky when you make changes to tsuki-macros, like adding a new macro and bumping its version. You update tsuki to use this new macro, but you forget to update the version number in tsuki's Cargo.toml to reflect the new version of tsuki-macros. Everything works fine locally because Cargo is pulling the correct version from your local macros directory.

However, when you publish tsuki, users who already have an older version of tsuki-macros in their Cargo registry cache might run into issues. They'll get errors like this:

error[E0432]: unresolved import `tsuki_macros::class`
   --> /home/ultimaweapon/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tsuki-0.3.1/src/lib.rs:310:9
    |
310 | pub use tsuki_macros::class;
    |         ^^^^^^^^^^^^^^^^^^^ no `class` in the root
    |

This happens because the published tsuki crate is trying to use a macro (class) that doesn't exist in the older version of tsuki-macros that the user has cached. This is super frustrating, especially since everything was working perfectly during local development. The core issue here stems from the disconnect between the actual version of the local dependency and the version specified in the dependent crate's Cargo.toml.

The current system relies heavily on the developer to manually keep these versions in sync, and as we all know, humans make mistakes! Forgetting to update the version number is an easy oversight, particularly when you're rapidly iterating on both crates simultaneously. This oversight can lead to broken builds for users and unnecessary bug reports, which nobody wants.

Furthermore, this problem can be particularly insidious because it doesn't manifest during local testing. Since Cargo prioritizes the local path dependency, the developer might not even realize there's an issue until after the crate is published and users start reporting problems. This delayed feedback loop makes it harder to catch and fix these kinds of version mismatches.

To make matters worse, this issue can be amplified in larger projects with multiple interconnected crates. If you have a chain of dependencies where each crate relies on a local path dependency, the chances of accidentally introducing a version mismatch increase significantly. Keeping track of all these dependencies and their respective versions can become a real headache, even with good organizational practices.

Ultimately, the problem boils down to the fact that the Cargo.toml file requires redundant information. When a path is specified, Cargo already has access to the dependency's Cargo.toml file and, therefore, its version. Requiring the developer to manually specify the version creates an opportunity for errors and inconsistencies.

Proposed Solution: Making Version Optional with Path Dependencies

Okay, so how do we fix this? The proposal is simple: make the version field optional when you're using the path attribute to specify a dependency.

Here's the idea: if the version isn't explicitly specified, Cargo should automatically fetch the version directly from the Cargo.toml file of the dependency located at the specified path. This removes the need for manual version synchronization and eliminates the risk of accidentally publishing with an outdated version.

So, in our example above, the Cargo.toml for tsuki would look like this:

[package]
name = "tsuki"
version = "0.3.1"
edition = "2024"

[dependencies]
tsuki-macros = { path = "macros" }

Notice that we've removed the version = "0.1.0" line. When you run cargo publish, Cargo will automatically read the version from the tsuki-macros crate's Cargo.toml file. This ensures that the published crate always uses the correct version of the local dependency.

This approach offers several key advantages:

• Eliminates Version Mismatches: By automatically fetching the version from the dependency's Cargo.toml, we completely eliminate the possibility of accidentally publishing with an outdated version. This ensures that users always get the correct version of the dependency, preventing frustrating build errors.
• Simplifies Development Workflow: Developers no longer need to manually keep track of dependency versions in multiple Cargo.toml files. This simplifies the development workflow and reduces the risk of human error.
• Improves Code Reliability: By ensuring that dependencies are always up-to-date, we improve the overall reliability of the code and reduce the likelihood of bugs caused by version incompatibilities.
• Enhances User Experience: Users will have a smoother and more predictable experience when using crates that rely on local path dependencies. They won't have to deal with unexpected build errors or compatibility issues caused by version mismatches.

To be clear, this proposal only applies when the path attribute is used. If the dependency is being fetched from a registry (like crates.io), the version field would still be required. This is because Cargo needs to know which version to download from the registry.

Potential Considerations and Edge Cases:

• Performance: There might be a slight performance overhead associated with reading the dependency's Cargo.toml file during the publishing process. However, this overhead is likely to be minimal and well worth the benefits of preventing version mismatches.
• Circular Dependencies: Cargo already has mechanisms in place to detect and prevent circular dependencies. This proposal should not introduce any new issues in this area.
• Workspaces: This proposal should be compatible with Cargo workspaces. Within a workspace, Cargo already has a good understanding of the relationships between crates, so automatically fetching the version from the dependency's Cargo.toml should work seamlessly.

Benefits and Use Cases

This change would be incredibly helpful in a variety of scenarios, particularly when you're actively developing multiple crates in tandem. Imagine you're building a library with a companion macro crate. You're constantly making changes to both, and it's easy to forget to update the version in the main library's Cargo.toml. With this proposal, you wouldn't have to worry about it!

Another great use case is for projects that use internal tooling or code generation. You might have a crate that generates code based on a schema defined in another crate. By making the version optional, you can ensure that the generated code is always compatible with the latest version of the schema.

Conclusion: A Small Change with a Big Impact

Making the version field optional when using the path attribute for dependencies might seem like a small change, but it could have a significant impact on the Rust ecosystem. It would eliminate a common source of errors, simplify the development workflow, and improve the overall reliability of Rust crates.

Let's make publishing Rust crates a little less painful, shall we? What do you guys think? Share your thoughts and let's discuss the pros and cons of this proposal!