Loose dependency ranges on bigint crates may result in a version mismatch #4477
Comments
mzabaluev
changed the title
A temporary fix to get movement CLI to compile, until diesel-rs/diesel#4477 is fixed.
|
I acknowledge that this can be an issue in certain cases, but I do not consider that to be a bug in diesel as there is no better way for us to handle this while not issuing a new major diesel release. We need to keep support for older versions of the Closed as won't fix |
|
Yes, it would require a new major release to fix, but the current cargo manifest of diesel is buggy as it claims support for any combination of those crates' versions in the full Cartesian product of the given ranges, which is not true. |
|
As written several times before: We currently don't accept any kind of changes that would require a major version bump. That's something that is not up to discussion, at least not without clear evidence that this is a wide spread problem that impacts the majority of diesel users. |
Setup
Versions
Feature Flags
numericProblem Description
The bigint crate dependencies are given as loose ranges:
bigdecimal in turn depends on bigint, but with a more rigid range as is customary for 0.x dependencies in cargo (e.g. bigdecimal 0.4.7 depends on num-bigint ^0.4). Usually there is no problem as there is a single num-bigint version to settle on.
However, in a large workspace that has diesel in the dependency tree, multiple versions of num-bigint or bigdecimal may be pulled by different crates. This can lead to a different version of num-bigint being selected for diesel than the one selected for bigdecimal, resulting in a compilation failure due to missing num-bigint trait implementations for the version required by diesel.
Here's an example: movementlabsxyz/aptos-core#132
Checklist
closed if this is not the case)
The text was updated successfully, but these errors were encountered: