Circular dev dependency

I have two crates, one that is a platform-independent crate, and another which implements traits there for the web platform. In the first crate, I use the second crate as a dev-dependency in order to write documentation. However, cargo doesn't let me publish this to crates.io since when publishing the first crate, the second isn't uploaded yet. How can I work around this?

Provided that just the simultaneous uploading is problematic, it's in principle possible to publish without any checks by using the --no-verify flag of cargo publish.

I don't have sufficient information about your use-case to be able to verify whether what you're trying makes sense in the first place, whether there are any other problems with what you're doing and consequently whether or not your crates will be usable after publishing them this way. Put provided everything works appropriately when you test it locally and you just need to "simultaneously" publish two crates, this might be a legitimate option.

Also, since this is about documentation, probably you need to do the publishing in relative quick succession if you want docs.rs to succeed. And even then I'm not 100% certain that docs.rs can generate links across crates when the target crate hasn't been documented yet. So please don't blame me if you end up needing to publish some follow-up point releases because the first try didn't work :sweat_smile:.

1 Like

That doesn't work unfortunately as even with the flag crates.io still rejects the publish.

The relevant toml is here.

I didn't think there really were any limits as to what can be uploaded via cargo publish. I'm curious as to what kind of error message you're getting.

In any case, it might make sense to wait for advice from people more experienced with publishing crates than me :slight_smile:

The error is "the remote server responded with an error: no known crate named avalanche-web". I'm only using the dev dependency so doc tests can work, so theoretically I could remove the dev dependency for publishing, but that seems really awkward, so would love if there was a better way to do this. Any way to gate dependencies for local compilation or something like that?

In case it only checks for crate existence, but not for the particular version, it could make sense to release some empty crate on version 0.0.0 just so the crate exists. No idea if that will solve the problem; again, don't blame me if this results in suboptimal results, and feel free to wait for a second opinion from others :slight_smile:

And also note that the docs.rs build queue is currently empty / quite short, so you might need to be extra quick with uploading multiple interdependent crates in succession, unless building the documentation will work without that dev-dependency being present.

1 Like

That worked, thanks! Seems like crates.io only verifies crate existence, not version match. If anyone maintaining crates.io sees this, please don't patch this loophole, this is what --no-verify was made for imo :slight_smile: .

1 Like

Thinking about this again, I think the current restrictions do actually make a lot of sense. You've gotta render pages like this properly after all; and that works as long as the crate exists at all. E.g. if the particular version doesn't exist, then the link that would be created in the dependencies list, e.g. something like https://crates.io/crates/avalanche-web/range/%5E0.2.0, still links to the crate's page, just displaying a little error message in the corner that says "No matching version of crate 'avalanche-web' found for: ^0.2.0". So there would be no need for crates.io to check for the presence of the specific required version of dependency being available, if the goal is only to generate a non-broken website.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.