rust-analyzer: Autopublishing to crates.io is broken

Autopublishing has been broken since January. There were a few causes for this that have been fixed and at least one more to go. I probably should have raised an issue for this when I started looking into it, but better late than never. Some previous discussions on #14827 and https://github.com/pksunkara/cargo-workspaces/pull/92

The remaining (known) issue causes publishing to fail with:

failed to select a version for the requirement `ra_ap_mbe = "=0.0.154"`
  candidate versions found which didn't match: 0.0.149, 0.0.148, 0.0.146, ...
  location searched: crates.io index
  required by package `ra_ap_cfg v0.0.154 (/home/runner/work/rust-analyzer/rust-analyzer/target/package/ra_ap_cfg-0.0.154)`
  perhaps a crate was updated and forgotten to be re-vendored?
error: unable to publish package ra_ap_cfg

i.e. it’s trying to publish ra_ap_cfg, but can’t because ra_ap_mbe hasn’t been published yet. ra_ap_cfg has only a dev-dependency on ra_ap_mbe. We probably should just have the autopublish workflow remove all dev dependencies before it publishes. I’m currently looking for an existing tool to do that. If there isn’t one, then perhaps we can add something to cargo-workspaces. @pksunkara, do you have any thoughts as to whether something like that might belong in cargo-workspaces?

About this issue

Original URL
State: closed
Created a year ago
Comments: 26 (26 by maintainers)

Most upvoted comments

Yup, “publish upon merge into master if version in Cargo.toml is different” is the way to go.

The main question is how we can make sure that the r-a crates don’t depend on local only changes

We should only depend on crates.io versions of the crates anywhere. That means that changing these crates requires a chain of two PRs, but that’s Ok; that’s exactly the workflow one would use if these crates were in a separate repo.

To make this easier, we should pull all crates to top-level Cargo.toml, and use only .workspace = true dependencies, ensuring that there’s only one place to patch dependencies.

matklad on Jun 19, 2023

Looks like the relevant line is:

warning: timed out waiting for `ra_ap_vfs v0.0.161` to be available in registry `crates-io`

It then subsequently failed while trying to publish ra_ap_base_db v0.0.161 because ra_ap_vfs v0.0.161 wasn’t available yet (it is now).

The timeout warnings looks to have come from cargo, which has a 60 second timeout.

What I don’t understand, is why cargo-workspaces didn’t then wait for the new version to be available. It has a timeout of 300 seconds for the version to appear in the index, but as far as I can see from the logs, it never printed out “waiting…”, which makes it look as though it found the new version of the first check.

davidlattimore on Jul 10, 2023

As a dependent of ra_ap_rust-analyzer and a bunch of its sibling crates: THANK YOU SO MUCH FOR FIXING THIS! 🙏

regexident on Jul 3, 2023

Finally worked in https://github.com/rust-lang/rust-analyzer/actions/runs/5437937695.

lnicola on Jul 2, 2023

Woohoo! Thanks for your patience and help everyone 😃

davidlattimore on Jul 2, 2023

I think 4 is the right approach of managing dependencies.

At that point, it might make sense to move these crates out into separate repositories.

We don’t really need to do that though. icu4x keeps yoke in the repository itself but publishes it independently.

pksunkara on Jun 19, 2023