Cargo - Publish crate from workspace where a newer version of another crate depends on that version

1

So, I just wrote these two commit messages, to be able to publish a new version of a crate in between those:

    Restore correct dependency.

...

    Cargo won't publish any crate in the same workspace with a new version if another crate in the same workspace depends on that very version of the crate, which is not published yet. So we need to artificially temporarily break the dependencies of the other crate to allow publishing its dependency.

The workspace contains a crate providing a trait and another one providing a derive macro for that trait.
I made changes to the trait (make it unsafe) and adjusted the derive macro accordingly.
Then I bumped the versions of both crates and updated the dependency in the main crate to the new one.
Then I tried to first publish the macro crate, since the other crate relies on its new version:

~/RustroverProjects/repr-discriminant/repr-discriminant> cargo publish -p repr-discriminant-derive 
    Updating crates.io index
    Updating crates.io index
error: failed to select a version for the requirement `repr-discriminant-derive = "^1.2"`
candidate versions found which didn't match: 1.1.7, 1.1.6, 1.1.5
location searched: crates.io index
required by package `repr-discriminant v2.1.0 (/home/neumann/RustroverProjects/repr-discriminant/repr-discriminant)`

Well, shoot.
How do I handle these kind of changes if cargo forbids me to publish a dependency first.
Why does this even fail? I never tried to publish repr-discriminant anyway.
I hacked around this, by artificially breaking the version constraints with the commits mentioned above, but this is very unergonomic. How do I correctly deal with this kind of dependent changes?

2

How do you declare the repr-discriminant-derive dependency in repr-discriminant? Simply

repr-discriminant-derive = "^1.2"

as the error message suggests?

You might need to change that to

repr-discriminant-derive = { path = "path/to/repr-discriminant-derive", version = "^1.2" }

for cargo publish to be able to build repr-discriminant locally during the publishing of repr-discriminant-derive. At least this is my setup and I never had such an error before.

3

I personally deal with it by publishing in a specific order and bumping versions gradually, but yeah, it is an awful experience from cargo.

4

I don't like this solution because it requires the user to have downloaded the other crate to the respective folder. This is not how I like to publish my crates.
If you suggest an intermediate change, imho this is not less worse than artificially breaking the version constraints to satisfy cargo.

I don't like this either, since I want to separate my software development and VCS workflow from my crate publishing workflow. I don't want cargo to force me to change one crate, and then publish it, before I can make related changes to another crate. In my case it'd be especially bad: I'd need to implement a derive macro for a trait that does not exist yet.

5

This is not true if your user downloads the repr-discriminant crate from crates.io.

6

Interesting. I didn't know that there's a fallback to the registry. Is this a new feature of cargo or was this always possible? I faintly remember that using local paths, also relative ones, was discouraged once due to the concerns I mentioned above.

7

The docs on multiple locations were written 6 years ago:

If Cargo ever treated the combination of path/git with version differently, I don't recall it.