3 ms·

> My ideal dependency manager would allow me to specify each and every dependency that is required to work on my projects. It should be easily reproducible, dec

> My ideal dependency manager would allow me to specify each and every dependency that is required to work on my projects. It should be easily reproducible, declarative and easy to upgrade. To me it feels like what's left out here is the fact that you need the amount of dependencies that you have to be reasonable in the first place, otherwise no single piece of software is going to help you all that much. For example, a new project that was created with "create-react-app" takes 181 MB of space on disk and has 35'894 files in it. That includes about 1467 modules, all for a relatively simple web application. It doesn't matter if you're using package.json/package.lock, or any other tool or solution out there - with that amount of dependencies you're simply not doing dependency "management" of any kind. I'd argue that if you have >100 dependencies in your project, it's probably too big, unless you have a team that's dedicated to managing and auditing all of them. Of course, no one actually audits their dependencies when faced with such large numbers, and so what's left for most developers is to just trust what's out there.

cwp 5y ago
You're not wrong, but that's a different problem. Nix makes sure that you get a predictable and reproducible tree of dependencies, and allows different applications to depend on different versions of the same dependencies. That is, it's a solution to DLL hell. It's solid engineering based on solid theory, and it really does let you manage configuration with a level of reliability that most other package managers only pretend to have. Now auditing dependencies, knowing that the packages you depend on aren't malicious and have no known vulnerabilities... well, that's a whole separate problem. And yeah, we don't really have a solution to that right now. The best we can do, as you say, is keep the attack surface small. But if we did try to solve the auditing problem, the solution would have to sit on top of nix or something like it. If you can't precisely specify a dependency graph and reliably install from that specification, it doesn't matter how good your auditing is or what sort of system of trust you can create. You don't know what you're getting anyway.
- omegalulw 5y ago
  +1 a good dependency manager should 1) pull all necessary packages for you 2) build them if required. It's your job when downloading a package to use or when adding a dependency to make sure you trust the source - this is not a dependency management problem. A good dependency manager should help you better filter trusted sources or at least have a good build file layout to make it obvious what the sources are but that's it.
krab 5y ago
I don't have an issue with the size of a project. On the other hand, I worry about a large number of dependencies and the need to understand the security and compatibility models of their respective authors. I'm fine to depend on, say, JVM or Qt - large projects. Not with thousands of small packages developed by thousands of independent developers.

cwp 5y ago

You're not wrong, but that's a different problem. Nix makes sure that you get a predictable and reproducible tree of dependencies, and allows different applications to depend on different versions of the same dependencies. That is, it's a solution to DLL hell. It's solid engineering based on solid theory, and it really does let you manage configuration with a level of reliability that most other package managers only pretend to have. Now auditing dependencies, knowing that the packages you depend on aren't malicious and have no known vulnerabilities... well, that's a whole separate problem. And yeah, we don't really have a solution to that right now. The best we can do, as you say, is keep the attack surface small. But if we did try to solve the auditing problem, the solution would have to sit on top of nix or something like it. If you can't precisely specify a dependency graph and reliably install from that specification, it doesn't matter how good your auditing is or what sort of system of trust you can create. You don't know what you're getting anyway.

omegalulw 5y ago
+1 a good dependency manager should 1) pull all necessary packages for you 2) build them if required. It's your job when downloading a package to use or when adding a dependency to make sure you trust the source - this is not a dependency management problem. A good dependency manager should help you better filter trusted sources or at least have a good build file layout to make it obvious what the sources are but that's it.

krab 5y ago

I don't have an issue with the size of a project. On the other hand, I worry about a large number of dependencies and the need to understand the security and compatibility models of their respective authors. I'm fine to depend on, say, JVM or Qt - large projects. Not with thousands of small packages developed by thousands of independent developers.