5 ms·

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

by tonsky 1y ago

Revisional_Sin 1y ago
So you need to test if the version worked yourself (e.g. via automated tests)? Seems better to have the library author do this for you and define a range.
Joker_vD 1y ago
> If that version doesn’t work, you can try another one. And how will this look like, if your app doesn't have library C mentioned in its dependencies, only libraries A and B? You are prohibited from answering "well, just specify all the transitive dependencies manually" because it's precisely what a lockfile is/does.
- deredede 1y ago
  It's not "all the transitive dependencies". It's only the transitive dependencies you need to explicitly specify a version for because the one that was specified by your direct dependency is not appropriate for X reason.
- tonsky 1y ago
  Maven's version resolution mechanism determines which version of a dependency to use when multiple versions are specified in a project's dependency tree. Here's how it works: - Nearest Definition Wins: When multiple versions of the same dependency appear in the dependency tree, the version closest to your project in the tree will be used. - First Declaration Wins: If two versions of the same dependency are at the same depth in the tree, the first one declared in the POM will be used.
  - Joker_vD 1y ago
    Well, I guess this works if one appends their newly-added dependencies are appended at the end of the section in the pom.xml instead of generating it alphabetically sorted just in time for the build.
    - yawaramin 1y ago
      Maven pom.xml files are maintained by hand, not by some code generation tool.
deredede 1y ago
Alternative answer: both versions will be picked up. It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.
- shadowgovt 1y ago
  This points to a software best-practice: "Don't leak types from your dependencies." If your package depends on A, never emit one of A's structs. Good luck finding a project of any complexity that manages to adhere to that kind of design sensibility religiously. (I think the only language I've ever used that provided top-level support for recognizing that complexity was SML/NJ, and it's been so long that I don't remember exactly how it was done... Modules could take parameters so at the top level you could pass to each module what submodule it would be using, and only then could the module emit types originating from the submodule because the passing-in "app code" had visibility on the submodule to comprehend those types. It was... Exactly as un-ergonomic as you think. A real nightmare. "Turn your brain around backwards" kind of software architecting.)
  - deredede 1y ago
    I can think of plenty situations where you really want to use the dependency's types though. For instance the dependency provides some sort of data structure and you have one library that produces said data structure and a separate library that consumes it. What you're describing with SML functors is essentially dependency injection I think; it's a good thing to have in the toolbox but not a universal solution either. (I do like functors for dependency injection, much more than the inscrutable goo it tends to be in OOP languages anyways)
    - shadowgovt 1y ago
      I can think of those situations too, and in practice this is done all the time (by everyone I know, including me). In theory... None of us should be doing it. Emitting raw underlying structures from a dependency coupled with ranged versioning means part of your API is under-specified; "And this function returns an argument, the type of which is whatever this third-party that we don't directly communicate with says the type is." That's hard to code against in the general case (but it works out often enough in the specific case that I think it's safe to do 95-ish percent of the time).

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

by tonsky 1y ago

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

Revisional_Sin 1y ago

So you need to test if the version worked yourself (e.g. via automated tests)? Seems better to have the library author do this for you and define a range.

Joker_vD 1y ago

> If that version doesn’t work, you can try another one. And how will this look like, if your app doesn't have library C mentioned in its dependencies, only libraries A and B? You are prohibited from answering "well, just specify all the transitive dependencies manually" because it's precisely what a lockfile is/does.

deredede 1y ago
It's not "all the transitive dependencies". It's only the transitive dependencies you need to explicitly specify a version for because the one that was specified by your direct dependency is not appropriate for X reason.
tonsky 1y ago
Maven's version resolution mechanism determines which version of a dependency to use when multiple versions are specified in a project's dependency tree. Here's how it works: - Nearest Definition Wins: When multiple versions of the same dependency appear in the dependency tree, the version closest to your project in the tree will be used. - First Declaration Wins: If two versions of the same dependency are at the same depth in the tree, the first one declared in the POM will be used.
- Joker_vD 1y ago
  Well, I guess this works if one appends their newly-added dependencies are appended at the end of the section in the pom.xml instead of generating it alphabetically sorted just in time for the build.
  - yawaramin 1y ago
    Maven pom.xml files are maintained by hand, not by some code generation tool.

deredede 1y ago

Alternative answer: both versions will be picked up. It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.

shadowgovt 1y ago
This points to a software best-practice: "Don't leak types from your dependencies." If your package depends on A, never emit one of A's structs. Good luck finding a project of any complexity that manages to adhere to that kind of design sensibility religiously. (I think the only language I've ever used that provided top-level support for recognizing that complexity was SML/NJ, and it's been so long that I don't remember exactly how it was done... Modules could take parameters so at the top level you could pass to each module what submodule it would be using, and only then could the module emit types originating from the submodule because the passing-in "app code" had visibility on the submodule to comprehend those types. It was... Exactly as un-ergonomic as you think. A real nightmare. "Turn your brain around backwards" kind of software architecting.)
- deredede 1y ago
  I can think of plenty situations where you really want to use the dependency's types though. For instance the dependency provides some sort of data structure and you have one library that produces said data structure and a separate library that consumes it. What you're describing with SML functors is essentially dependency injection I think; it's a good thing to have in the toolbox but not a universal solution either. (I do like functors for dependency injection, much more than the inscrutable goo it tends to be in OOP languages anyways)
  - shadowgovt 1y ago
    I can think of those situations too, and in practice this is done all the time (by everyone I know, including me). In theory... None of us should be doing it. Emitting raw underlying structures from a dependency coupled with ranged versioning means part of your API is under-specified; "And this function returns an argument, the type of which is whatever this third-party that we don't directly communicate with says the type is." That's hard to code against in the general case (but it works out often enough in the specific case that I think it's safe to do 95-ish percent of the time).