Cargo update hangs with a specific configuration of dependency crates

[golddranks]

It appears to be a some kind of a livelock. It never prints anything after Updating registry https://github.com/rust-lang/crates.io-index, but if I enable the tracelog, it seems to be doing copious amounts of... something. Eventually I stopped it with ctrl-c. Here's a gist of the tracelog: https://gist.github.com/golddranks/3c8bfb3dfe7b8e26b8052cdfd02af7da

Here's a repository that triggers the behaviour for me. I tried it on two networks, but unfortunately I haven't been able to try it on multiple computers. I also tested it on the latest nightly, latest stable (1.20) and the stable before that (1.19). They all seem to trigger it. I'll be curious to see if it hangs on other people's computers too. https://github.com/golddranks/cargo_test

This affects my daily work so hopefully this gets resolved soon. First of all, I'm curious to hear whether it happens on other computers too!

[golddranks]

I got a confirmation that it happens on other people's computers too. It seems that it happens with the combination of the crates rust-s3 and postgres in the dependencies. Updated the demo repository.

[pgerber]

Sounds like #4066

[pgerber]

Looks like this is caused by the update of rust-s3 from 0.6.1 to 0.6.2. I'm experiencing the same issue with the aws-sdk-rust crate which hasn't been updated for some time. My guess is that they have some dependency in common that causes the issue.

You may want to explicitly use rust-s3 0.6.1 for now:

rust-s3 = "=0.6.1"

[pgerber]

@golddranks I looked at it a bit closer, the generic-array crate appears to cause the issue. Looks like postgres 0.15 depends on 0.7 which conflict with some of the other dependencies.

Generic-array has been updated and the next release should fix the issue.

You can directly use the git repository from Cargo.toml if you want:

postgres = { git = "https://github.com/sfackler/rust-postgres" }

[golddranks]

It seems that rust-s3 0.6.2 contained breaking changes. I reported the issue: durch/rust-s3#18

Some takeaways:

1. A re-affirmation that RFC for Public/Private Dependencies rfcs#1977 is a very valuable RFC to have :)
2. Also having tooling that helps reasoning with API changes and version bumps would be valuable.
3. I don't understand why mismatching versions of generic-array (more accurately, it's typenum that breaks stuff?) often break the build even though any types of it are not exposed in the API (this time 0.7 in postgres and 0.8 in rust-s3, but these two crates don't interact! And as far as I know, generic-array doesn't contain any native dependencies, which would clash even without public API.), but that often seems to be the case. I'd be happy if someone could enlighten me.
4. Cargo should try and have some heuristic to fix Abort crate resolution if too many candidates have been tried #4066

Closing this issue.

[golddranks]

I encountered another breaking change (namely sfackler/rust-postgres#290 ) with crates updating to generic-array 0.8 which brought me to reopen this issue.

Is there a some reason that cargo can't find compatible versions of the crates? generic-array seems to induce the breakage, but it isn't a public dependency of the crates as far as I know, yet cargo seems to consider it as such. Why?

[alexcrichton]

This is likely #4066

[carols10cents]

Closing this since it sounds like it will be solved by solutions to #4066 and/or implementing public/private dependencies.

[golddranks]

For the record, this was caused by generic-array having a needlessly strict dependency constraint: fizyk20/generic-array#49 (comment)