Hacker News Reader

Comment by ant6n | Hacker News Reader

You mean sort of like npm?

npm is an example of a bad solution to dep management. So I want you to run my 6kb node.js script you need to:

1) Build obtain node for your platform (and now you've hit the exact problem I'm talking about) 2) install npm (which I can't really define as a dep, you're just expected to have it) 3) install all the deps I've defined and hope they all work on the version / configuration of node you have (execjs only works on node 0.10 but you have v4? Too bad! You didn't apply the increased memory patch before building node? Too bad!)

The ideal here to reiterate is given nothing but your installed OS, I should be able to give you a file that will go from nothing to a running app, and from the running app to a clean system if you decide to remove it, without you having to have any prerequisites (no node, no chef, no docker, etc)

I don't think you can really complain about having to have node.js installed in order to run a node.js script.

If you want self-contained binaries, learn Go. If you want lightweight scripts that run effortlessly on all unix systems, learn bash scripting. It sort of sounds to me like you're complaining about not being able to shoehorn your chosen language into all possible scenarios.

I think that's a very reasonable thing to complain about in the context of dependency management. The runtime (node.js) and it's compile time + run time options are actually a dependancy of your application.

As an end user, I shouldn't be expected to know how to configure x dependancy for my system to run y app and as a software developer I shouldn't have to build / package apps to match the client's system configuration.

The sticking point is (back to my point) that the vast majority of distributions don't give the app a way to manage the deps and get specific deps in required, the best you can do is list x as a dep in your package and hope that it won't break your app or the system in some way.

Agreed. Have two dependencies which have the same underlying dependency? Install and compile that dependency twice (with two different versions, by the way)[1]. Want to use grunt? Need to set that up as a dependency for your project, but only for development. A problem while installing? Have fun with the debug output detailing the fetching a building of every dependency, and every dependency's dependency, and every dependency's dependency's dependency... etc.

[1] I can't believe how many distinct copies and versions of the 'shell' module are downloaded and compiled when pulling in a seemingly simple set of modules.

I wouldn't use npm as an example of a stellar package manager.

Not using it as an example of a 'stellar' package manager. Just one where the dependencies can be defined with version. I was under the impression that apt-get will just use the most recent version.

apt-get/dpkg do have the ability to specify package versions, including specifying versions equal to, greater than, or less than. It also has the ability to specify build time and run time dependencies separately.

You can specify a version. The real trouble is that you generally cannot have multiple versions of the same package installed on the same system. Thus, if multiple packages specify different versions as dependencies, you're hooped.

So that is something npm does, AFAIK. Isn't it even possible to have multiple different versions of a sub package in the dependency tree of one project?

The downvotes are undeserved. The solution is npm on the OS level - you specify the version of the dependency you require, and each version is installed across the OS only once.

Reply on news.ycombinator.com