cyclic dependency getrandom ===> getrandom

[jrouaix]

Hello, I have a pretty big workspace with lots of cumulated dependencies and I got stuck on a cyclic dependency conundrum :

error: cyclic package dependency: package `getrandom v0.2.3` depends on itself. Cycle:
package `getrandom v0.2.3`
    ... which satisfies dependency `getrandom = "^0.2.0"` of package `ahash v0.7.4`
    ... which satisfies dependency `ahash = "^0.7.0"` of package `hashbrown v0.11.2`
    ... which satisfies dependency `hashbrown = "^0.11"` of package `indexmap v1.7.0`
    ... which satisfies dependency `indexmap = "^1.5"` of package `serde_json v1.0.68`
    ... which satisfies dependency `serde_json = "^1.0"` of package `wasm-bindgen v0.2.78`
    ... which satisfies dependency `wasm-bindgen = "^0.2.78"` of package `js-sys v0.3.55`
    ... which satisfies dependency `js-sys = "^0.3"` of package `getrandom v0.2.3`
    ... which satisfies dependency `getrandom = "^0.2"` of package `rand_core v0.6.3`
    ... which satisfies dependency `rand_core = "^0.6.0"` of package `rand_chacha v0.3.1`
    ............

Basically, through some features activation in random crates, getrandom is dependent on getrandom ...

Tried to remove cargo lock, to update all dependencies at the same time.

Checked if this was true (it is, there is a path with optional features activations that lead from getrandom to ... getrandom!)

Do you have an idea on how to get around this problem ?

P.S. : I'm really sorry to ask you this question, you are obviously not responsible for a dependency cycle going around multiple other crates all over crates.io. If you just have a clue on how to solve this or a hint to a channel I can ask this question to somebody able to answer, it's just about very fine for me ...

[jrouaix]

seems related to : tkaitchuck/aHash#95

[gilescope]

Just a thought but have you tried resolver="2" for cargo? (it might not aggregate quite so many features)

[newpavlov]

As noted in the aHash issue, probably the best place to fix this issue will be on the wasm-bindgen side. As a temporary workaround you could try to avoid enabling the serde feature in wasm-bindgen.

[jrouaix]

This works great :
tkaitchuck/aHash#95 (comment)
Until wanted to update sqlx to the latest version

Closing the issue as more follow up arriving on the aHash issue

[tomasro27]

@jrouaix @josephlr it looks like the issuue with ahash is still present.

wasm-bindgen has updated their crate and deprecated jsvalue. Are there any plans to update to latest wasm-bindgen and change the usage of jsvalue?

Thanks

[josephlr]

@tomasro27 I'm not sure I understand what you're talking about. The JsValue type is not deprecated, see https://docs.rs/wasm-bindgen/latest/wasm_bindgen/struct.JsValue.html

The only thing the wasm-bindgen crate deprecated was the "serde-serialize" cargo feature (and associated Serde functions), see rustwasm/wasm-bindgen#3031

We do not make use of that deprecated future, and we recommended that others do not as well. I don't think there's anything else for this crate to do here, but, as always, patches are welcome if they're is something that we can do.

[tomasro27]

Sorry about the confusion. wasm-bindgen deprecated JsValue::from_serde and JsValue::into_serde, not JsValue. They claim this way wasm-bindgen does not depend on serde_json and the cyclic should be fixed.
But getrandom still depends on wasm-bindgen 0.26.2 in which it is not deprecated yet. That's why I thought it might be a good idea to update to latest wasm-bindgen.

I tried updating wasm-bindgen to 0.2.84 (latest) on getrandom, and pulled that version on my project, but I still got the dependency cycle. So not sure what's the right fix then.
I was under the idea that wasm-bindgen would stop depending on serde_json if I use latest version, but given it is optional, maybe having other crates depend on serde_json triggers this dependency as well?

error: cyclic package dependency: package `ahash v0.7.6` depends on itself. Cycle:
package `ahash v0.7.6`
    ... which satisfies dependency `ahash = "^0.7.0"` of package `hashbrown v0.12.3`
    ... which satisfies dependency `hashbrown = "^0.12"` of package `indexmap v1.9.2`
    ... which satisfies dependency `indexmap = "^1.5.2"` of package `serde_json v1.0.93`
    ... which satisfies dependency `serde_json = "^1.0"` of package `wasm-bindgen v0.2.84`
    ... which satisfies dependency `wasm-bindgen = "^0.2.84"` of package `js-sys v0.3.61`
    ... which satisfies dependency `js-sys = "^0.3"` of package `getrandom v0.2.81 (https://github.com/tomasro27/getrandom?rev=ddcf36ef7ee401af102debb9c758703b1e574461#ddcf36ef)`
    ... which satisfies dependency `getrandom = "^0.2.3"` of package `ahash v0.7.6`

[tomasro27]

I think this comment by you makes sense @josephlr
tkaitchuck/aHash#95 (comment)
In summary, some other dependency I have is using wasm-bindgen1 with the serde-serialize feature so I need to track down which dependencies are enabling that feature, and fix the issue there.

[josephlr]

@tomasro27 that is correct. Unfortunately, updating the version of wasm-bindgen doesn't make the cyclic dependency issue any better, as the deprecation of the Cargo feature is just a documentation change. The feature still exists in the latest version, and using it will cause problems.

[tomasro27]

For anyone that might find this helpful, you can run cargo metadata > metadata.json to generate a file with all the crates/dependencies on your project. Then find all usages of wasm-bindgen with the feature flag serde-serialize (make sure it is not a dev dependency, as that might be okay). After finding which crates depend on wasm-bindgen with the feature flag enabled, you will need to update those packages to the latest version that does not use the serde-serialize feature in their dependencies.