Hi. I myself package a large tree of dependencies, packaging myself OpenStack in Debian. For it, I am maintaining 500+ packages, 300+ being Python, making myself the biggest contributor of Python modules in Debian. So I do understand what you went through. There are other apps where I've been through craziness, like Puppet 7 (50+ new dependencies that we introduced for Bookworm). The Go ecosystem is crazy too... However, what you should reconsider, is if it was really reasonable to have a so huge amount of dependencies in your app. Dependencies made of literally 20 lines of codes in some modules really are a pain at so many levels. The Debian approach isn't to blame, the Node.JS ecosystem and how it deals with dependency is. What's amazing, is that packaging your app for Debian made you realize how broken your chain of dependency wasn't maintainable, when on the opposite side of things, there's even dependencies you didn't know about yourself even if it was your own application! Dependency management is fully part of maintaining a project, and you realized it the hard way. Thanks for sharing your experience.
Never understood why package managers don't use content addressing. - In fact, I think it would be the ideal application for IPFS. (yes, sometimes you need to translate names to their content hash, but that could be a small top-layer of the system)
One thing you got a little bit wrong. It wasn't /usr/bin/node, but /usr/sbin/node (notice the s) that the hamradio thingy was using. Still, there was a namespace clash, as both were in the $PATH.
Hi. I myself package a large tree of dependencies, packaging myself OpenStack in Debian. For it, I am maintaining 500+ packages, 300+ being Python, making myself the biggest contributor of Python modules in Debian. So I do understand what you went through. There are other apps where I've been through craziness, like Puppet 7 (50+ new dependencies that we introduced for Bookworm). The Go ecosystem is crazy too...
However, what you should reconsider, is if it was really reasonable to have a so huge amount of dependencies in your app. Dependencies made of literally 20 lines of codes in some modules really are a pain at so many levels. The Debian approach isn't to blame, the Node.JS ecosystem and how it deals with dependency is.
What's amazing, is that packaging your app for Debian made you realize how broken your chain of dependency wasn't maintainable, when on the opposite side of things, there's even dependencies you didn't know about yourself even if it was your own application!
Dependency management is fully part of maintaining a project, and you realized it the hard way. Thanks for sharing your experience.
thank you for your contributions. Debian is my favorite distro
This was a very strange premise, but the blink 182 reference is 99% of why I clicked
SAMEEE
NixOS does solve _some_ of these issues, but there's definitely a lot to be learned still.
Yeah i love nixos
Andrew uses nixos as his main os
Never understood why package managers don't use content addressing.
- In fact, I think it would be the ideal application for IPFS.
(yes, sometimes you need to translate names to their content hash, but that could be a small top-layer of the system)
Deno uses URLs, which kind of piggybacks on DNS. IPFS also has a protocol way to assign hashes to names.
One thing you got a little bit wrong. It wasn't /usr/bin/node, but /usr/sbin/node (notice the s) that the hamradio thingy was using. Still, there was a namespace clash, as both were in the $PATH.
I liked this
Me too.
No, there must be some kind of solution, like namespaces for apps and dependencies. We figured out DNS, this isn't that different.
nice
Haha cool 💪
what is andrew's religion?