Availability: crates.io vs releases

[shoffmeister]

Current behavior 😯

It seems as if the release process does not integrate well with crates.io

https://github.com/Byron/gitoxide/releases has gix at 0.61.1, https://crates.io/crates/gix has it at 0.61.0

Starship release 1.81.1 (https://github.com/starship/starship/releases) released five days ago wants to consume gix 0.61.1

Because crates.io does not have that version of gix, a cargo install starship will fail:

Updating starship
    Updating crates.io index
  Installing starship v1.18.1
    Updating crates.io index
error: failed to compile `starship v1.18.1`, intermediate artifacts can be found at `/tmp/cargo-install7MYCrN`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Caused by:
  failed to select a version for the requirement `gix = "^0.61.1"`
  candidate versions found which didn't match: 0.61.0, 0.60.0, 0.58.0, ...
  location searched: crates.io index
  required by package `starship v1.18.1`
  perhaps a crate was updated and forgotten to be re-vendored?


Updated 0 packages.
Failed to update starship.

Expected behavior 🤔

In the immediate case here, cargo install starship should work because tagging of gix on github should follow a release onto crates.io, too.

In case there is release automation, reliable uploading to crates.io should become part of the automation.

(There is a point to be made that starship should not release unless all deps are on crates.io, but then ...)

Git behavior

No response

Steps to reproduce 🕹

No response

[NobodyXu]

gix 0.61.1 is yanked due to breaking compilation error unless gix-transport is upgraded at the same time.

Though I agree that it would be better to update the release, to mark them as "yanked" on github.

[wadeduvall]

Fixed downstream, you can probably close this.

[Byron]

Thanks for reporting!

It's incredibly hard to do this right and I hope that over time, I get good enough to get everything right. Thus, I am glad it was fixed downstream by avoiding the yanked version in the manifest instead.

Apparently what would have worked is to yank the patch release, but let that be followed up by another patch which reverts to the last known valid state, allowing Cargo to skip the yanked version instead of failing.

However, somehow I feel that when using cargo install, it should be less strict to make installations work in this case. Or in other words, installations could be a different mode of operation than cargo build done by devs locally. CC @weihanglo to share this case and ideas.

Closing the issue, as suggested, with the option of creating a special patch release if more of downstream is reporting such issues.

[weihanglo]

rust-lang/cargo#7169 is the relevant issue.

The installation method on starship.rs website is with the --locked flag, so that yanked version can still be selected. I'd generally suggest following what the author recommends. That being said, I understand the inconvenience 😞.

For yanking a version, I would recommend what has been told in the cargo yank manual:

A common workflow is to yank a crate having already published a semver compatible version, to reduce the probability of preventing dependent crates from compiling.

Not a hard requirement but it would be nicer if we follow that :)

[Byron]

rust-lang/cargo#7169 is the relevant issue.

Thanks, I am watching that now.

A common workflow is to yank a crate having already published a semver compatible version, to reduce the probability of preventing dependent crates from compiling.

Not a hard requirement but it would be nicer if we follow that :)

That's exactly what I learned the hard way here 🤦‍♂️. Amazing 😅.