4 ms·
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 ra
by driggs 2y ago
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.
- Uvix 2y agoIf 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.
- driggs 2y agoThe 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.
- phinnaeus 2y agoThe 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.
- zahlman 2y agoAs another library developer, of course I want to test against multiple versions. Or more accurately, I don't want to prevent my users from using different versions prematurely. My default expectation is that my code will work with a wide range of those versions, and if it doesn't I'll know - because I like to pay attention to other libraries' deprecations, just as I'd hope for my users to pay attention to mine. Lockfiles aren't helpful to me here because the entire point is not to be dependent upon specific versions. I actively want to go through the cycle of updating my development environment on a whim, finding that everything breaks, doing the research etc. - because that's how I find out what my version requirements actually are, so that I can properly record them in my own project metadata. And if it turns out that my requirements are narrow, that's a cue to rethink how I use the dependency, so that I can broaden them. If I had a working environment and didn't want to risk breaking it right at the moment, I could just not upgrade it. If my requirements were complex enough to motivate explicitly testing against a matrix of dependency versions, using one of those "other tools", I'd do that instead. But neither way do I see any real gain, as a library developer, from a lock file.
- imtringued 2y ago>If I had a working environment and didn't want to risk breaking it right at the moment, I could just not upgrade it. The point of a lockfile is to only upgrade when you want to upgrade. I hope you understand that.
- zahlman 2y agoWhy do I need a special file in order to not do something?
- orf 2y agoThat’s not the perspective that OP was sharing, though.
- remram 2y agoYou literally phrased it as "I have no idea why". You can't be upset if someone feels you don't understand why.
- Pannoniae 2y 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.)