We've been working in a workspace for several years on prerelease versions that used path dependencies. Now that we're releasing 1.0.0 for most crates, I'm working on changing those into version dependencies. This works for the most part - and we tried this before as a test, but our repo dependencies got more complicated since I now realize - but I run into problems where:

• A --(path)--> B (B unpublished)
• B --(dev-dependency version) --> A

And now any command that previously worked with -p A fails with "which version?"

What we'd like is for anything with a dependency on A to be a versioned dependency such that they can ship independently, but keep A ready for the next release. Anything that requires changes in A we haven't shipped yet can't ship then, so it keeps the dependency tree clean since crates.io won't let us publish a crate with an unresolved dependency.

I've tried a number of things including strict dependencies vs. dev-dependencies adherence on who can use a version (via workspace) vs. path, but that hasn't worked. In fact, it's made the multi-version problem worse because the more version dependencies there are, the more A@1.0.0 and A@1.1.0 there are (and for any crate).

Is there any good way split dependencies in such a way that [dependencies] use version while [dev-dependencies] use path? When I tried that, cargo errs that a dependency must have a single source regardless of target.

2 posts - 2 participants

Read full topic