4 ms·

The notion that one should always pin their dependency version falls apart when considering that package managers like cargo when considering libraries. Librari

The notion that one should always pin their dependency version falls apart when considering that package managers like cargo when considering libraries. Libraries hard pinning dependencies causes a world of trouble. This is exactly why cargo uses a lock file that does pin your dependencies as described for binary crates, but does not use the same mechanism for libraries. https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-hav...

finnh 3y ago
Good point, diamond-pattern dependencies can get hellish. In the past, rather than deal with shadowing etc, I've resorted to choosing versions of my major dependencies that use the same version of their underlying dependency (for example, sync my GRPC lib with other HTTP client libs so they all use the same version of Netty - this is in the Java world).
belinder 3y ago
Wouldn't the library dependency hierarchy have been figured out during development in order to get it to a state that can compile? I'm assuming if you're pinning a dependency you already have something that compiles
- paholg 3y ago
  Let's say crate B depends on crate A with a pinned dependency, and uses one of its types in a public interface. Crate C depends on them both. It now can't bring in updates to A until B does, and when B updates that's a breaking change, so it better bump its major version. Take a look at this trick, for example, for foundational crates updating their major version: https://github.com/dtolnay/semver-trick https://github.com/dtolnay/semver-trick Now imagine that being an issue every single patch update.
  - belinder 3y ago
    Yeah I see what you mean, it's not so much about the first time it's deployed but for future updates where you want to update one dependency but another one requires it to stay the way it is
_ahxg 3y ago
Quite interesting. That doesn't seems like a complete falling apart but rather a (unintentional?) attempt of best of worlds since once set your dependencies on your binary, they will be pinned until you manually run a cargo update. Granted that the supply chain attack defense would fall on the hands of the users of the library. Unless the library writer aggressively pins of dependencies on the Cargo.toml (not the default semver action), problematic, but at least Cargo allows multiple versions of dependencies on a program, on Python for instance this is much complicated scenario (but still the smallest of the dependencies problems there).
- steveklabnik 3y ago
  This behavior as very intentional, patterned after Bundler.
epage 3y ago
That guidance has changed and will hit stable for 1.74 (5 weeks). For the new guidance: https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-ca... See also https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html https://blog.rust-lang.org/2023/08/29/committing-lockfiles.h...

finnh 3y ago

Good point, diamond-pattern dependencies can get hellish. In the past, rather than deal with shadowing etc, I've resorted to choosing versions of my major dependencies that use the same version of their underlying dependency (for example, sync my GRPC lib with other HTTP client libs so they all use the same version of Netty - this is in the Java world).

belinder 3y ago

Wouldn't the library dependency hierarchy have been figured out during development in order to get it to a state that can compile? I'm assuming if you're pinning a dependency you already have something that compiles

paholg 3y ago
Let's say crate B depends on crate A with a pinned dependency, and uses one of its types in a public interface. Crate C depends on them both. It now can't bring in updates to A until B does, and when B updates that's a breaking change, so it better bump its major version. Take a look at this trick, for example, for foundational crates updating their major version: https://github.com/dtolnay/semver-trick https://github.com/dtolnay/semver-trick Now imagine that being an issue every single patch update.
- belinder 3y ago
  Yeah I see what you mean, it's not so much about the first time it's deployed but for future updates where you want to update one dependency but another one requires it to stay the way it is

_ahxg 3y ago

Quite interesting. That doesn't seems like a complete falling apart but rather a (unintentional?) attempt of best of worlds since once set your dependencies on your binary, they will be pinned until you manually run a cargo update. Granted that the supply chain attack defense would fall on the hands of the users of the library. Unless the library writer aggressively pins of dependencies on the Cargo.toml (not the default semver action), problematic, but at least Cargo allows multiple versions of dependencies on a program, on Python for instance this is much complicated scenario (but still the smallest of the dependencies problems there).

steveklabnik 3y ago
This behavior as very intentional, patterned after Bundler.

epage 3y ago

That guidance has changed and will hit stable for 1.74 (5 weeks). For the new guidance: https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-ca... See also https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html https://blog.rust-lang.org/2023/08/29/committing-lockfiles.h...