Also sprach Xidorn Quan: > Should we have some kind of policy to address duplicate dependencies > in Gecko as well? Maybe I'm missing something but I don't think I'm > aware of any previous discussion about this.
Deduplicating crate dependencies has so far been a mostly heroic undertaking done by individuals such as eijebong, so having a policy built in to "./mach vendor rust" that prevents duplication is probably a good idea! However, I want to talk a little bit about _why_ we see so many duplicate crates and what causes it. It is my experience that far too many dependencies are defined on exact version numbers, e.g. "log = 0.3.9", which effectively forces us to vendor that exact version in-tree. In some cases we see this reproduce throughout a crate’s dependency chain, where different crates depend on minutely different versions of crate D (v0.4.0, v0.3.9, v0.3.7) causing us to have to vendor and compile all of them, even as part of a single build: A |-- B v1.2.0 | |-- C v2.0.1 | |-- D v0.4.0 | |-- C v2.0.0 | |-- D v0.3.9 | |-- E v0.2 | |-- D v0.3.7 As kats points out, unravelling this spider web is not trivial. You often run into cases where some crate depends on a particular version of something, but you can’t upgrade that because something else depends on a too specific version, and you can’t upgrade that again because it would cause an API change or behaviour change that requires specialist peer review in an unrelated component. In conclusion, my plead to Rust crate maintainers is to be generous with what version range you tolerate for dependencies. As most crates respect semantic versioning you can be somewhat confident that relying on v1.2 rather than v1.2.1 will keep your program working when v1.2.2 is released. The most common argument I hear against tolerating a wider dependency range for dependencies is “reproducible builds”. Well, for binaries it is recommended you check in the Cargo.lock file, and for Gecko we do that for all components, including libraries. We additionally vendor the source code, allowing us to do hermetically sealed builds. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
