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?

5 posts - 3 participants

Read full topic