-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Having rand
0.5 and rand
0.6 with default features turned off in the crate graph results in a compliation error
#645
Comments
How many versions of Are default features enabled for one version of Rand but not the other? I guess the solution is we should make a shim for Rand 0.5 on 0.6. |
If both |
The problem then is that You might be able to work around this by directly depending on Otherwise a shim for 0.5 around 0.6 will unify the feature flags. |
I saw something probably related to this where a
Adding a fake dependency on |
The main issue here is that this can easily break the compilation for the downstream users without any visible semver bump. Imagine this scenario:
This breaks the usual expectation that 1) dependency X shouldn't break the compilation of a completely unrelated dependency Y, and 2) that you can simultaneously have two versions of the same crate in your crate graph. This wouldn't be a big of a deal for any random crate ('random' as in an arbitrarily picked crate which usually only have a few users on average, no pun intended 😃), but |
Probably
As long as all versions of @koute if In any case, maybe we can just push out a new release of |
I encountered this today in my side project, and it manifested as the same error that dvdplm mentioned above. The trick of temporarily adding |
As far as I can tell, I'm running into the same issue. The problem manifests as my builds randomly breaking when I've made no changes. Very infuriating. It's happened twice now, but the error messages are different from the ones above. Apologies for stretching the page, but I'm posting the full error log below so that people will be able to find this issue with a Google search.
Running I didn't think to save the dependency graph before running
|
@aleksijuvani I think you are right — and yet I don't know of a good solution to this issue. |
Running |
I had to run specifically |
Had to run `cargo update -p rand_core:0.2.1`, see rust-random/rand#645
Hi there, just chiming in to report that this has suddenly become an issue in CI, e.g., https://travis-ci.org/dalek-cryptography/x25519-dalek/jobs/482946540 |
@hdevalence something is forcing Optional, enabled-by-default features are highly problematic, as is relying on no dependency requesting some feature. We really need a better |
Note: Hang tight, I am proposing a solution in a new issue... #702 |
Choose version 0.7.1, as it depends on rand 0.5. Currently, all aflak dependencies depend on rand 0.5. We cannot afford to use the latest version of uuid (currently 0.7.3), as it depends on rand 0.6, however rand 0.6 and 0.5 are not compatible [0]. [0] rust-random/rand#645
Choose version 0.7.1, as it depends on rand 0.5. Currently, all aflak dependencies depend on rand 0.5. We cannot afford to use the latest version of uuid (currently 0.7.3), as it depends on rand 0.6, however rand 0.6 and 0.5 are not compatible [0]. [0] rust-random/rand#645
As the next step in #3506, and following up from #3542 and #3558, upgrade Parity Ethereum (now OpenEthereum) from [2.6.8] (Dec 2019) to [2.7.2] (Feb 2020), the last release in the 2.x series. This harmonizes our dependency graph with upstream, fixing numerous build errors from the upgrade and eliminating multiple versions of the same crates. This concerns the [bn], [ethabi], [ethabi-contract], [ethabi-derive], [ethereum-types], [keccak-hash], [primitive-types], and [uint] crates as well as their transitive dependencies and their interdependencies. The [near/bn] fork exists to upgrade [bn]'s [rand] dependency. That's necessary because of a particularly complex dependency issue (rust-random/rand#645) in old versions of rand. We will eliminate the fork going forward once upstream upgrades their dependency (I will open a pull request for them). The upstream changelog for 2.7.2 is at: https://github.com/openethereum/openethereum/blob/v2.7.2/CHANGELOG.md The upstream diff from 2.6.8 to 2.7.2 is at: openethereum/openethereum@v2.6.8...v2.7.2 [2.6.8]: https://github.com/openethereum/openethereum/releases/tag/v2.6.8 [2.7.2]: https://github.com/openethereum/openethereum/releases/tag/v2.7.2 [near/bn]: https://github.com/near/bn [bn]: https://crates.io/crates/bn [ethabi]: https://crates.io/crates/ethabi [ethabi-contract]: https://crates.io/crates/ethabi-contract [ethabi-derive]: https://crates.io/crates/ethabi-derive [ethereum-types]: https://crates.io/crates/ethereum-types [keccak-hash]: https://crates.io/crates/keccak-hash [primitive-types]: https://crates.io/crates/primitive-types [rand]: https://crates.io/crates/rand [uint]: https://crates.io/crates/uint
bar
and depend onrand
0.5.foo
and depend onrand
0.6 withdefault-features = false
and onbar
.foo
.Resulting error:
Automatic reproduction:
Rust version:
Crate graph from
Cargo.lock
:The text was updated successfully, but these errors were encountered: