Node NPM rocks(techno-weenie.net)
techno-weenie.net
Node NPM rocks
http://techno-weenie.net/2011/7/16/npm-rocks/
3 comments
The obvious question is how much work it'll be to turn each NPM into a system package for production use. It took us months to straighten out a nest of servers which had assorted unique versions of code smuggled onto them with ad hoc single-language tools completely lacking RPM integration, and we're not about to go there again. The sample package.json doesn't show any way to list native (non-node) dependencies, which is not a good sign.
I think the idea is to NOT do that. If you're doing it in production, you probably run your node in user level anyway, so you should have node installed via nvm or similar tool.
Why would you want package.json to list native dependencies, shouldn't that be the responsibility of the npm package author? Usually npm packages that compile to native code will run 'make' on 'npm install'.
Another reason that you would NOT want this is because npm packages could potentially use older conflicting versions of the same library. NPM can manage this internally -- you wouldn't want rpm to install 2 different versions of the same package globally.
In the contrived example below, cluster & express are using 2 different versions of the 'log' npm package, but the main system using cluster & express have no clue that there are 2 different versions installed.
Why would you want package.json to list native dependencies, shouldn't that be the responsibility of the npm package author? Usually npm packages that compile to native code will run 'make' on 'npm install'.
Another reason that you would NOT want this is because npm packages could potentially use older conflicting versions of the same library. NPM can manage this internally -- you wouldn't want rpm to install 2 different versions of the same package globally.
In the contrived example below, cluster & express are using 2 different versions of the 'log' npm package, but the main system using cluster & express have no clue that there are 2 different versions installed.
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
└─┬ [email protected]
├── [email protected]
├── [email protected]
└── [email protected]Sounds like you should be using Chef or Puppet to manage these kinds of dependencies.
Last I looked, both Chef and Puppet were meta-tools that launch all the other third-party tools I don't want involved. Are either of them solid enough now to actually replace the system package manager? Can they answer questions like "why does /etc/foo exist, which package created that?"
A few of us in the ruby world use rip, https://github.com/defunkt/rip, which also isn't needed at runtime. Unfortunately, the ruby community never took much interest.
The problem with rip is the lack of cross platform support due it's usage of symlinks.
Its management and mixture of git/gems can make things a bit complicated.
Not to mention that it plays with your environment variables (RUBYLIB) making things not as transparent as npm.
Node really endorsed npm and both worked together. RubyGems until 1.9.1 was never part of "Ruby", even while is extensively used as package manager.
Worse than that, Ruby-Core doesn't use it and cripples it to avoid the startup pain it could be, instead of making it integral part of Ruby.
Its management and mixture of git/gems can make things a bit complicated.
Not to mention that it plays with your environment variables (RUBYLIB) making things not as transparent as npm.
Node really endorsed npm and both worked together. RubyGems until 1.9.1 was never part of "Ruby", even while is extensively used as package manager.
Worse than that, Ruby-Core doesn't use it and cripples it to avoid the startup pain it could be, instead of making it integral part of Ruby.
I love how easy it is to use conflicting versions of packages. Haven't needed it in practice, yet, but I'm sure it'll only be time.