7 ms·

Ok, but what happens when lib-a depends on lib-x:0.1.4 and lib-b depends on lib-x:0.1.5, even though it could have worked with any lib-x:0.1.*? Are these librar

Ok, but what happens when lib-a depends on lib-x:0.1.4 and lib-b depends on lib-x:0.1.5, even though it could have worked with any lib-x:0.1.*? Are these libraries just incompatible now? Lockfiles don't guarantee that new versions are compatible, but it guarantees that if your code works in development, it will work in production (at least in terms of dependencies). I assume java gets around this by bundling libraries into the deployed .jar file. That this is better than a lock file, but doesn't make sense for scripting languages that don't have a build stage. (You won't have trouble convincing me that every language should have a proper build stage, but you might have trouble convincing the millions of lines of code already written in languages that don't.)

aidenn0 1y ago
> I assume java gets around this by bundling libraries into the deployed .jar file. That this is better than a lock file, but doesn't make sense for scripting languages that don't have a build stage. (You won't have trouble convincing me that every language should have a proper build stage, but you might have trouble convincing the millions of lines of code already written in languages that don't.) You are wrong; Maven just picks one of lib-x:0.1.4 or lib-x:0.1.5 depending on the ordering of the dependency tree.
- yladiz 1y ago
  How do you change the order?
  - adrianmsmith 1y ago
    You go into your pom.xml file (bunch of <dependency>) using a text editor and change the order.
- Tadpole9181 1y ago
  Maven will also silently choose different minor and major versions, destroying your application. Sometimes at compile time, sometimes at runtime. Java dependency management is unhinged, antiquated garbage to anyone who has used any other ecosystem.
  - oftenwrong 1y ago
    Maven is not Java, though.
    - Tadpole9181 1y ago
      Gradle suffers the same exact issue by default, because it inherits it from Maven (they use the same repository). You need to go out of your way to enable strict versioning policies and lock files. Maven and Gradle make up the vast majority of all Java projects in the wild today. So, effectively, Maven is Java in terms of dependency management.
      - quacker 1y ago
        > Gradle suffers the same exact issue by default, because it inherits it from Maven It's not the exact same issue because Gradle and Maven have different conflict resolution: Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph. from https://gradle.org/maven-and-gradle/ https://gradle.org/maven-and-gradle/
shadowgovt 1y ago
> Are these libraries just incompatible now? Python says "Yes." Every environment manager I've seen, if your version ranges don't overlap for all your dependencies, will end up failing to populate the environment. Known issue; some people's big Python apps just break sometimes and then three or four open source projects have to talk to each other to un-fsck the world. npm says "No" but in a hilarious way: if lib-a emits objects from lib-x, and lib-b emits objects from lib-x, you'll end up with objects that all your debugging tools will tell you should be the same type, and TypeScript will statically tell you are the same type, but don't `instanceof` the way you'd expect two objects that are the same type should. Conclusion: `instanceof` is sus in a large program; embrace the duck typing (and accept that maybe your a-originated lib-x objects can't be passed to b-functions without explosions because I bet b didn't embrace the duck-typing).

aidenn0 1y ago

> I assume java gets around this by bundling libraries into the deployed .jar file. That this is better than a lock file, but doesn't make sense for scripting languages that don't have a build stage. (You won't have trouble convincing me that every language should have a proper build stage, but you might have trouble convincing the millions of lines of code already written in languages that don't.) You are wrong; Maven just picks one of lib-x:0.1.4 or lib-x:0.1.5 depending on the ordering of the dependency tree.

yladiz 1y ago
How do you change the order?
- adrianmsmith 1y ago
  You go into your pom.xml file (bunch of <dependency>) using a text editor and change the order.
Tadpole9181 1y ago
Maven will also silently choose different minor and major versions, destroying your application. Sometimes at compile time, sometimes at runtime. Java dependency management is unhinged, antiquated garbage to anyone who has used any other ecosystem.
- oftenwrong 1y ago
  Maven is not Java, though.
  - Tadpole9181 1y ago
    Gradle suffers the same exact issue by default, because it inherits it from Maven (they use the same repository). You need to go out of your way to enable strict versioning policies and lock files. Maven and Gradle make up the vast majority of all Java projects in the wild today. So, effectively, Maven is Java in terms of dependency management.
    - quacker 1y ago
      > Gradle suffers the same exact issue by default, because it inherits it from Maven It's not the exact same issue because Gradle and Maven have different conflict resolution: Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph. from https://gradle.org/maven-and-gradle/ https://gradle.org/maven-and-gradle/

shadowgovt 1y ago

> Are these libraries just incompatible now? Python says "Yes." Every environment manager I've seen, if your version ranges don't overlap for all your dependencies, will end up failing to populate the environment. Known issue; some people's big Python apps just break sometimes and then three or four open source projects have to talk to each other to un-fsck the world. npm says "No" but in a hilarious way: if lib-a emits objects from lib-x, and lib-b emits objects from lib-x, you'll end up with objects that all your debugging tools will tell you should be the same type, and TypeScript will statically tell you are the same type, but don't `instanceof` the way you'd expect two objects that are the same type should. Conclusion: `instanceof` is sus in a large program; embrace the duck typing (and accept that maybe your a-originated lib-x objects can't be passed to b-functions without explosions because I bet b didn't embrace the duck-typing).