

Node NPM rocks - technoweenie
http://techno-weenie.net/2011/7/16/npm-rocks/

======
prodigal_erik
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.

~~~
mtodd
Sounds like you should be using Chef or Puppet to manage these kinds of
dependencies.

~~~
prodigal_erik
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?"

------
cldwalker
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.

~~~
luislavena
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.

------
mtodd
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.

