undefined | Better HN

0 pointsdriggs1y ago0 comments

Just because someone has a different perspective than you doesn't mean they don't "understand".

Lockfiles are an anti-pattern if you're developing a library rather than an application, because you can't push your transitive requirements onto the users of your library.

0 comments

Uvix1y ago

If you're developing a library, and you have a requirement for what's normally a transitive dependency, it should be specified as a top-level dependency.

driggsOP1y ago

The point is that if I'm writing a library and I specify `requests == 1.2.3`, then what are you going to do in your application if you need both my library and `requests == 1.2.4`?

This is why libraries should not use lockfiles, they should be written to safely use as wide a range of dependencies' versions as possible.

It's the developers of an application who should use a lockfile to lock transitive dependencies.

phinnaeus1y ago

The lock file is for developers of the library, not consumers. Consumers just use the library’s dependency specification and then resolve their own dependency closure and then generate a lock file for that. If you, as a library developer, want to test against multiple versions of your dependencies, there are other tools for that. It doesn’t make lock files a bad idea in general.

1 more reply

orf1y ago

That’s not the perspective that OP was sharing, though.

remram1y ago

You literally phrased it as "I have no idea why". You can't be upset if someone feels you don't understand why.

Pannoniae1y ago

"I have no idea why" the industry went there. One can understand a technology or a design pattern yet think it's completely idiotic. (low-hanging fruit: JavaScript, containers, etc.)

j / k navigate · click thread line to collapse