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.)

▲

shadowgovt 4 days ago | parent | next [-]

> 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 4 days ago | parent | prev [-]

> 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.

▲

Tadpole9181 4 days ago | parent | next [-]

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 4 days ago | parent [-]

Maven is not Java, though.

▲

Tadpole9181 4 days ago | parent [-]

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 2 days ago \| parent [-]
		> 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/

▲

yladiz 4 days ago | parent | prev [-]

How do you change the order?

	▲	adrianmsmith 4 days ago \| parent [-]
		You go into your pom.xml file (bunch of <dependency>) using a text editor and change the order.