A recent trend in package management is to install packages locally to an application. Composer for PHP is doing it by default, npm for node.js is doing it by default, and a few others are following along.
You know who did that schnazz before both of them? GetSparks. Yep, the GetSparks team did it before it was cool.
Now, I’m not going to say “I told you so,” but there were some serious doubters — there were even dissenters on the team. But it ultimately boiled down to that fact that global/system-level packages are often painful to deal with. I honestly think those opposed to local packages just wanted to stick to what they were comfortable with.
I understand versioning someone else’s packages seems a little redundant at first, but in reality, what other qualms are there? If you install system-level packages, you invite yourself to dependency hell — and all of the sudden you need extra hacks to make it work right.
Reality: rvm for ruby and virtualenv for python are workarounds for a problem.
I love when things “just work.” If I can check out a repository and just run `node app.js`, I’m happy. If I’m putzing around with rvm, virtualenv, bundler, or pip, I’m annoyed.
Looking back, I’m glad we made that choice with GetSparks — way back in January 2011, before node and Composer.
Package code becomes your responsibility, and it shoudn’t be treated like a black box. Having packages installed locally invites you to poke around and understand what’s going on, instead of just opening an issue on github when problems arise.
PPPS: What, is the npm registry going stay online 30 years from now, when your code is mission-critical legacy crap that nobody except $250/hr consultants will touch? Version those modules.