cyclic package dependency: package ahash v0.7.4 depends on itself

[bit-ranger]

Updating crates.io index
error: cyclic package dependency: package ahash v0.7.4 depends on itself. Cycle:
package ahash v0.7.4
... which is depended on by hashbrown v0.11.2
... which is depended on by indexmap v1.7.0
... which is depended on by serde_json v1.0.64
... which is depended on by wasm-bindgen v0.2.74
... which is depended on by js-sys v0.3.51
... which is depended on by getrandom v0.2.3
... which is depended on by ahash v0.7.4
Error: Process completed with exit code 101.

more detail in github actions:

https://github.com/bit-ranger/chord/runs/2950729626?check_suite_focus=true

[LLBlumire]

I believe, though am not certain, that indexmap updating its version of hashmap to a more modern one that depends on ahash, is the cause

indexmap-rs/indexmap@8e843a9

[vicky5124]

A temporal fix for most people will be to force version 1.6 as a dependency by adding indexmap = "=1.6.2" to Cargo.toml's [dependencies] field, this should work even if IndexMap is only a subdependency (such as for example on h2 or serde_json).

[pepoviola]

A temporal fix for most people will be to force version 1.6 as a dependency by adding indexmap = "=1.6.2" to Cargo.toml's [dependencies] field, this should work even if IndexMap is only a subdependency (such as for example on h2 or serde_json).

Hi @vicky5124, thanks for your comment I just use this workaround and works as expected :)

[tkaitchuck]

@bit-ranger I am confused as to why this is happening.
getrandom's toml indicates it depends on js-sys only on wasm32 (which doesn't appear to be the arch in the linked build) additionally, it only depends on it if the js feature is enabled which aHash does not request.

Is the build above cross compiling and it's just not obvious? Is there some other package that is also depending on getrandom and Cargo is turning on the feature for both it and aHash in an effort to avoid duplication of the crate?

[lucacasonato]

@tkaitchuck Some other crate in the crate tree is enabling the js feature, and ahash is affected through feature unification.

Also crate resolving does not take into account the target arch. When building the crate tree, all crates for all targets are taken into account (not just the ones required for the active target arch).

[tkaitchuck]

The chain works as follows:

• aHash depends on getrandom for randomness.
• getrandom depends on wasm-bindgen only if the js feature is enabled. (This is up to the user application, but it may be relevant)
• wasm-bindgen has an optional dependency on serde_json which is disabled by getrandom. - So to enable this part of the cycle an app would have to also depend on wasm-bindgen and enable the serde feature. If an application does this it provides no value to getrandom other than shrinking the total binary size by unifying the crate with and without the feature.
• serde_json has a dependency on indexmap only if the preserve_order feature is enabled (it is off by default). So to enable this part of the cycle the app would have to also depend on serde_json and enable preserve_order. Similar to the above this provides no value to wasm-bindgen.
• indexmap depends on hashbrown but disables the ahash feature. So to complete the cycle an application would have to depend on hashbrown.

This cycle requires enabling 4 non-default features at different points. Of these js may be necessary, but the following 3 are an artifact of unification. Several of these are features are quite common, and are likely to be enabled in many applications. AHash could make getrandom optional, but it wouldn't actually break the cycle, it would just add one more feature required to complete it.

I think the most advantageous place to break the cycle would be as close to below getrandom as possible, because it should not be pulling in a bunch of extra dependencies, and serde support is not providing it any value.

One way to do this would be to refactor some of the wasm-bindgen code into a "core" package which could be depended on directly but which does not itself have the serde feature.

Another option would be to modify getrandom to support the js features without depending on js-sys or wasm-bindgen. I don't see any clear path that looks easy. Perhaps @josephlr or @newpavlov have some thoughts on this.

[josephlr]

@tkaitchuck thanks for the detailed writeup. As one of the maintainers of getrandom, I agree that this is a problem that should be fixed. Exactly who should fix it is a harder question. Thankfully, this bug is hard to hit.

One way to do this would be to refactor some of the wasm-bindgen code into a "core" package which could be depended on directly but which does not itself have the serde feature.

I like this idea, we could have a wasm-bindgen-core crate that contains only:

• The contents of wasm_bindgen::prelude::*
• wasm_bindgen::JsCast
• wasm_bindgen::memory()

js-sys would then only depend on wasm-bindgen-core, the full wasm-bindgen would just reexport wasm-bindgen-core, and getrandom would just depend on wasm-bindgen-core and js-sys.

@alexcrichton would this be feasible?

I think the most advantageous place to break the cycle would be as close to below getrandom as possible, because it should not be pulling in a bunch of extra dependencies, and serde support is not providing it any value.

I completely agree, getrandom aims to have as few dependencies as possible. Other than all the wasm-bindgen stuff, we only depend cfg-if and "System ABI" crates like libc/wasi which just contain extern declarations. All of these are already dependencies of the standard library itself. The end goal is to have the functionality of getrandom in the standard library, but that's a ways off.

Another option would be to modify getrandom to support the js features without depending on js-sys or wasm-bindgen. I don't see any clear path that looks easy.

If this was possible, we would do it. We currently depend on 5 distinct imports:

• wasm_bindgen_macro::wasm_bindgen
  • Mandatory: required on wasm32-unknown-unknown to bind to JS APIs
  • Similar to extern "C" on other platforms
• wasm_bindgen::JsValue
  • Mandatory: used to interface with the wasm-bindgen glue code and refer to JS objects
• js_sys::global()
  • Needed to get the global context (so we can start calling methods)
  • Not Mandatory: Could just copy the relevant code from js_sys into getrandom.
• wasm_bindgen::JsCast
  • Only needed because we use js_sys::global()
• js_sys::Uint8Array
  • Similarly, we could just copy the relevant code from js_sys

Also crate resolving does not take into account the target arch. When building the crate tree, all crates for all targets are taken into account (not just the ones required for the active target arch).

@bit-ranger if you use resolver = "2" does this remedy your issue?

[alexcrichton]

Oh dear this is quite the quandry, and sorry that wasm-bindgen is the cause of this! (I agree that wasm-bindgen is proabably the best place to fix this)

That being said I don't have the energy nowadays to redesign wasm-bindgen and/or implement major changes like refactoring the crates. I would recommend to basically avoid the serde features in wasm-bindgen. The serde features in wasm-bindgen are actually quite small and are probably best done manually through js-sys anyway.

[StephanSchmidt]

"Thankfully, this bug is hard to hit."

I've got it in two projects, and only through second-level dependencies except for serde_json.

[s-panferov]

Unfortunately reqwest uses those features, which makes it quite hard to avoid.

[sindreij]

I also got hit by this in a project, after adding oauth2 (at least I think that was the cause).

Setting resolver = "2" made no difference.

Using indexmap = "~1.6.2" works as a workaround.

[StripedMonkey]

oauth2 and sqlx together cause this issue. Using indexmap = "~1.6.2" does solve this.

[FylmTM]

Hi,

Managed to run into this error, by having these 4 dependencies (all together):

[dependencies]
load_image = "2.15.1"
mongodb = "2.0.0"
reqwest = "0.11.4"
bevy = "0.5"

If I comment out any of these dependencies, it breaks cycle.

However, I did not managed to understand how exactly these 4 manage to get me into cycle.

Error for reference:

error: cyclic package dependency: package `ahash v0.7.4` depends on itself. Cycle:
package `ahash v0.7.4`
    ... which is depended on by `hashbrown v0.11.2`
    ... which is depended on by `indexmap v1.7.0`
    ... which is depended on by `serde_json v1.0.68`
    ... which is depended on by `wasm-bindgen v0.2.69`
    ... which is depended on by `js-sys v0.3.46`
    ... which is depended on by `getrandom v0.2.3`
    ... which is depended on by `ahash v0.7.4`

[videni]

I also have this issue, anyway to get arround this issue please?

error: cyclic package dependency: package `ahash v0.7.4` depends on itself. Cycle:
package `ahash v0.7.4`
    ... which is depended on by `hashbrown v0.11.2`
    ... which is depended on by `indexmap v1.7.0`
    ... which is depended on by `serde_json v1.0.64`
    ... which is depended on by `wasm-bindgen v0.2.74`
    ... which is depended on by `js-sys v0.3.51`
    ... which is depended on by `getrandom v0.2.3`
    ... which is depended on by `ahash v0.7.4`

[ngryman]

For those having sqlx as one of the dependencies, downgrading to 0.5.7 worked for me.
sqlx@^0.5.8 requires indexmap@^1.7.0, which makes it impossible to pin it to ~1.6.2 as suggested above.

[x1qqq]

I am having this issue and pinning indexmap's version isnt solving it
Issue popped up once i added rust-s3 crate to one of my workspace members

[tomasro27]

For anyone that might find this helpful, and pinning indexmap is not a solution, 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.

If the packages in question, are still using the feature flag serde-serialize on their latest version, you can fix the crate on a forked repository, and patch your crates in your project to use the custom version from your branch.

[vladimir-dd]

Hope this might be useful for anyone, who is not interested in building wasm targets - one of the easy ways to break this circular dependency is by disabling wasm dependencies of getrandom package. You can fork and update getrandom(example) or simply add the patch below to your Cargo.toml:

[patch.crates-io]
# workaround to break the circular dependency for ahash(https://github.com/tkaitchuck/aHash/issues/95)
getrandom = { git = 'https://github.com/vladimir-dd/getrandom.git'}

[elenakrittik]

Ran into this when tried to build latest amethyst. Forcing indexmap to =1.6.2 somehow increased dependency count to 300 (from ~180) and also raised a few warnings, but worked. Thanks for the tip!

[newpavlov]

@vladimir-dd
You do not need to replace getrandom outright. Simply do not enable the js feature and instead use a custom implementation.

[vladimir-dd]

@vladimir-dd You do not need to replace getrandom outright. Simply do not enable the js feature and instead use a custom implementation.

Agreed, good point. Unfortunately, in our case js feature was required by one of the transitive dependencies.

[tkaitchuck]

Can this now be closed, or should some of the feature flags be adjusted?

[tkaitchuck]

Closing as fixed via rustwasm/wasm-bindgen#3031
Anyone still experiencing this should read the comments there.