More relaxed dependencies?

[aviramha]

I noticed that some dependencies are defined very specifically, and some have more broad requirement:

ahash = "0.8"
anyhow = "1.0.71"
assert-json-diff = "2.0.2"
async-broadcast = "0.7.0"
async-stream = "0.3.5"
async-trait = "0.1.64"
backoff = "0.4.0"
base64 = "0.22.0"
bytes = "1.1.0"

I think it'd make the library nicer if we'd pin only what's needed to be pinned, for example, in our case it'd reduce compilation time + size because we can reuse the dependency instead of having different versions in the build.

If that suggestion makes sense, I'd be happy to send a PR that relaxes the dependencies.

[clux]

The dependency pins here only indicate minimums and we do in general we do run with pretty general (far-from-latest) version requirements. The specificity should not cause a problem (e.g. you would free to run any of anyhow versions newer than the 9mo old one we pinned without the pin constraining upwards).

For breaking changes, this is less true; we do auto-bump / dependabot these more aggressively (e.g. such as 0.8 -> 0.9, 1.X -> 2.X etc) because then a choice often has to be made. For a breaking change (where multiple versions cannot be made to coexist):

• if we don't bump, then users might not be able to use the newest version in their own deps
• if we do bump , then users might be forced to upgrade

and for these, I'd rather we make being out-of-date an explicit choice, rather than the default.

[goenning]

From what I understand, Cargo requires a = prefix to pin a dependency so the examples you shared above are not pinned, but this would be:

base64 = "=0.22.1"

[clux]

note that if you are getting multiple versions of dependencies in your build, presumably you have versions with incompatible versions listed in cargo tree -p duplicated-pkg. for that there's not much we can do, but maybe you can pick parent packages that avoid this.

we only try to align and minimise our duplicates by checking for them in via cargo deny, but this is a best-effort thing. sometimes the ecosystem has not moved in one single step.

[aviramha]

Thanks for the elaborate explanation - I understand that I didn't get the resolution correctly.