Single-Version Packages.

[TyOverby]

In Piston, we have a pattern where in order to decouple dependencies and achieve maximum independence, we split up a interface and it's implementation(s) into multiple projects.

The interface does not depend on the implementations, but the opposite is true. For example:

• My App
  • piston
  • some_piston_backend
    • piston

What we would really like is a way to make sure that the two piston repositories in the tree are the exact same version. A user could theoretically pick piston-3.0 and some_piston_backend-1.0 (that depends on piston-1.0).

I'm not sure what resolution strategy Cargo is planning on using for this, but I would like the option as a maintainer of piston to be able to say "THERE CAN ONLY BE ONE" and fail at the cargo package fetching stage. Anything else would either run (and have terrible bugs) or fail at compile time with confusing error messages.

Edit: A more detailed example of what could go wrong: PistonDevelopers/piston#430

[bvssvni]

It would be nice to have a command in Cargo for getting a summary of the dependencies. Perhaps it could generate a graph or something. Maybe we could use the API and create a tool on top of Cargo.

I think we will manage to plan releases with check lists to get everything correctly. However, dependencies gets very complex over time.

[steveklabnik]

Eventually, Cargo will write out the resolved dependencies to a lockfile.

[wycats]

This problem is the kind of thing that led npm to peerDependencies. I suspect there are better solutions, and node folk consider peer dependencies a failure. I will continue to think about our available options.

[tomjakubowski]

Maven has a similar notion called 'provided dependencies'. It works pretty nicely.

[carols10cents]

This sounds like public dependencies, that is, once that RFC is implemented, some_piston_backend would list piston as a public dependency and cargo would reject resolutions for the crate graph of My App if they have different versions of the direct piston dependency and the some_piston_backend public piston dependency.

Please reopen if I'm missing something!