Things You Probably Didn’t Realize npm Could Do | Hacker News Reader

Things You Probably Didn’t Realize npm Could Do

blog.izs.me

54 pointsRaphael15 comments

The automatic dependency management that lets you have conflicting version dependencies is one of the big wins with commonjs and npm makes it so easy that it "just works".

npm is great, and isaac is usually very responsive on irc.

that being said, there's still something a little irksome about encouraging people to curl a .sh and pipe it to bash.

As a Node noob, I have to ask: is the tone of this article indicative of the general attitude and style of the Node community?

No, in fact this style is a little unusal for isaac. Maybe there was beer involved ; )

If you mean people being passionate about their software, re-thinking the conventions and sharing their ideas, then yes.

My favorite thing about npm is its 'utils' code:

https://github.com/isaacs/npm/tree/master/lib/utils/

I use code from there at least as often as I use actual modules.

I really enjoy npm and think it is a great way to handle node.js modules.

What is so seductive about reinventing package management but not finishing the job? Is this really that different than any of the other single-language ghettos which can't interop at all with the only package manager I care about, namely the one already on each of our systems that knows everything that's installed, and that our sysadmins have learned the ins and outs of? If I can't "yum install" a Node app and bring in its missing dependencies, I view any packaging the authors did as a waste of time, because I'm going to have to redo it anyway before it goes on our hardware.

I agree that the trend of single-language package managers is unwelcome, but that doesn't mean that package management as a field doesn't need to innovate. And building package manager that can co-exist with systems own package manager is a lot easier in many ways than building a new distro at the same time.

To "finish the job" one has to patch the native package managers themselves which is a huge undertaking. Neither DPKG nor RPM support installing multiple versions of the same package.

Furthermore, why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility to "finish the job"? Why can't DPKG and RPM just support multiple versions as well as the ability to recognize files outside their native database? Right now DPKG and RPM don't recognized software installed from source tarballs (./configure && make install).

Linear versioning has the baked-in promise that version N is no longer needed because version N+1 is substitutable for it. If that's not true, if apps legitimately depend on specific revisions of the library code (because its authors are not maintaining backwards compatibility), those library builds need different names so they can coexist in the filesystem and dependent apps can name the one they need. There's no reason to treat them as versions of the same package, because switching between them is effectively migrating from one dependency to another (which happens to have many authors in common).

> why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility

Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem.

> recognize files outside their native database

How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? You wouldn't know how to uninstall it cleanly, nor what its dependencies currently are (so you could ever safely uninstall anything without potentially breaking it), nor whether it'll be okay to clobber it with a legitimate version from a repository (or what might break if yum let you do it). I'm not that familiar with dpkg, but those are awfully fragile results just to avoid writing an rpmbuild .spec that definitely states these facts and then runs ./configure && make install.

If I seem like I have a grudge, it's because we spent months digging ourselves out of the hell of "this code is just somehow there on a few of our machines, but we don't know which version it was for which files, how they got there, or how to cleanly deploy a new server that actually works." Unfortunately the pain wasn't borne by the slobs whose negligence got us there over years. That's a drawback to startups—between failures and turnover, too many authors aren't required to work with reckless implementations long enough to learn how bad some ideas really are.

> If that's not true, if apps legitimately depend on > specific revisions of the library code (because its > authors are not maintaining backwards compatibility), > those library builds need different names so they can > coexist in the filesystem and dependent apps can name > the one they need.

Yes that's now RPM/DPKG did it so far, but it's nowhere near as flexible as proper built-in support for multiple versions. What if your app/library depends on exactly version 1.2.3 of libfoobar? What if another app/library depends on all versions >= 1.2.4 and < 1.3.0? You can easily specify that with RubyGems but it's hard to automatically support this in DPKG/RPM. It forces the DPKG/RPM packager to either impose arbitrary restrictions on what versions are packaged (and thus restricting which apps are installable) or to work around it in a stupid way by creating multiple packages, libfoobar1-2-3, libfoobar-1-2-5, libfoobar-2-0-0. If libfoobar 1.2.6 is released the packager has to manually rename libfoobar-1-2-5 to libfoobar-1-2-6 and manually rename the dependency names for packages that depended in foobar >= 1.2.4 && < 1.3.0.

This becomes messy and tiresome very quickly. Aren't computers supposed to help humans?

> Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem.

I don't see how sysadmins would reject proper support for multiple versions. They aren't losing any control over their system or any clarity.

> How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs?

Very useful because if those "random crap" exist then that means the sysadmin has knowingly installed them and wants to use them for a reason. You're basically saying "no user, this is what you want but I'm not going to allow it". I can't count the number of times where the user wants to upgrade libxyz to version 2.3.5, but the OS only packages 2.3.4, so the user resorts to installing from source only to find out that RPM/DPKG dependenceis don't like that. The user usually ends up uninstalling all those RPM/DPKG packages and ends up installing those things from source as well.

Gems only works because it's not only a package manager but also a monkey-patch for the Ruby interpreter which decides on the fly which files it should actually load. Nobody's going to be able to do that for every language runtime which has ever existed, so when someone screws up and releases an incompatible change, you have to give the new version's filesystem contents a different name, so dependencies have some way to specify which one they need. At that point it's clearer to rename the package as well.

I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. If you have actual sysadmins (not devs who had root by mistake and misused it) who are smuggling files on a production box that aren't owned by a package (even one they created themselves), I hope they'll still be around to suffer the hell they're creating.

You don't have to do that for every language. Just support multiple versions in DPKG/RPM so that the languages who do support RubyGems-style loading can have multiple versions. Right now converting gems to DPKG/RPM is all manual work with no good way to automate it. DebGem tries to work around it by making a DEB that includes all existing versions but it's far from optimal.

> I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are.

So... tell it what the dependencies are?

Autoconf configure scripts can check for arbitrary things. It's just package managers that insist on only listening to their own databases.

I guess there is no way to use the multiple version management with other languages?

Hands down the best 'language' package manager.

Reply on news.ycombinator.com