Hacker News Reader

"Zero" isn't a cost of anything -- there's no free lunch.

NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to

    function whatever() {
        return "WHHEEEEEEE!!!";
    }

and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously curated package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.

Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates.

Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.

And wait till you hear what a sufficiently smart compiler can do!

http://c2.com/cgi/wiki?SufficientlySmartCompiler

But there already exist package managers that let you pin to a specific version like he's saying they should e.g. Maven, so I don't think your link quite applies here.

Npm allows that too -- you just specify an explicit version number, e.g. "1.5.3" instead of "*" or "^1.5.3" etc.

My comment was against this belief that "smarter" tools in general are some sort of panacea.

For example pining to a specific version won't help you match if the package is removed altogether (as in this case), and ever worse if it's replaced afterwards by another (newly registered) with an incompatible same version out. It won't try to overwrite your specific install of course (since the version already matches what you have), but you'll feel the pain when you try to duplicate/deploy etc a new install with the same package listing -- suddenly the package either won't be there (or will be modified in the worst case scenario).

So, then we opt for ever more features of a "sufficiently smart package manager", e.g. signatures, permanence of anything published etc...

That's just a no-true-scotsman fallacy.

And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.

No, it's not an NTS fallacy. And the package manager is mostly useful for tracking updates and simplify the process; having it automatically update is completely optional, and personally, I never do.

Exactly. A notification that new updates are available would be nice, but I don't think automatic updates should be the default, even if "semantic versioning" says the update should be backwards compatible.

No, it's not an NTS fallacy.

No True Scotsman is so often mis-attributed, that the mis-attribution needs to be its own fallacy.

Exactly. That's the No True No True Scotsman Fallacy Fallacy.

Compare also with Fallacy Fallacy - just because the argument is fallacious, doesn't mean the overall point is wrong.

There's this "Tone Argument" Fallacy Fallacy. You can't win an argument by complaining that the other's tone is unpleasant. So that's a valid fallacy, but it only applies to a particular argument in a particular circumstance. Certain people on the Internet then make the illogical jump to the conclusion that they are therefore justified to use whatever tone they care to in any argument. (And lo and behold, they always "win" arguments.)

Without knowing much of how npm works, I'm going to assume you have ways of protecting yourself there too. If nothing else, good old "cp -r" can effectively let you pin to a version.

The point is that people use package managers and third party modules installed from them to automate tedious work, and anything automated will have the potential to do something other than what you want. Is that risk high? Not really, but it's not zero either.

Yes, but a sanely designed package manager will at least require that to be a new, versioned release. _Already published_ versions of a package should be immutable.

If you do that, won't you have to increment your version number? Because with npm, except for left-pad due to oddities of the npm-specific ^ semver operator, you always have to increment your version and you can always pin earlier versions. That said, the ^ sevmer operator would probably upgrade to your sabotaged version if you went from 1.2.3 to 1.2.4, and people would have to figure out what the other operators meant.

As to curated package managers, I'd consider them a great counter-example. Try installing a recent (5.x) version of node and postgres (9.4) on ubuntu. You can go through the rigmarole of adding an entirely new repository for postgres (apt.postgresql.org) since the debian distributed version of postgres is rather old (and ubuntu-version specific). You can also do the same thing with nodesource for nodejs, but if you install node on ubuntu, you'll get a packet radio service instead.

Curated package managers are very conservative and move very slowly. Javascript is a relatively fast-moving, pretty anarchic environment.

The lesson of left-pad is probably: vendor your node deps and check them in. And also: npm probably needs to be replaced with a write-once store with cryptographic signing of packages. You still have to trust the author, but that's the point of open source. We're built on trust.

Node has a history of kicking out a new release virtually every week, often with crazy breaking changes. Quite sensibly the Debian packagers decided not to try to keep up with that game. There is an easy-to-add on repo if you really want it, although Typescript works just fine in the packaged version so I haven't.

Not sure what your point is on postgres, since 9.4 is right there in the repo.

postgres-9.4 is available in ubuntu 14.10 and later. If you're in 14.04 or 12.04 (current LTS versions), you have to use the postgres-maintained source. The process isn't super-simple.

Node moves fast, sure. I'm not sure I agree with your "crazy breaking" modifier there: I regularly do dev work against the latest 5.x branch of node, and rarely if ever have to worry about breaking changes. Then again, I'm just doing plain old restful api and business logic stuff, so maybe if you're dealing with the c++ interface it's a different environment.

Even still, I think it's easy enough to see from our disagreement over "too fast" and "quite sensibly" that there's plenty of ways to be a programmer. Rapid improvement can be kind of exhausting (especially if you get behind) but it's also a great way to see new ideas emerging. One of the things I actually love about the javascript world is how quickly things move. Things evolve very quickly because there's so much churn, speedy releases, pressure for mindshare, and so on. It's fascinating, both technologically and sociologically.

It ought to be pretty straightforward to say "apt-get install nodejs-5.3" and have that Just Work, but by the time the curators get around to updating their packages, you may well be a month or three behind. (again, unless you've updated your sources.list.d to include the nodesource repo).

So yeah: curated package managers have a place in the world for sure. But the trade-off here is that you're not getting the Latest and Greatest. Joyent tried to Slow Things Down with the 0.10 branch of node, and you see where that got them.

You could, and that's why it's trivial package manager hygiene to pin versions and always test before upgrading versions.

Yeah, except nobody does it. It's really the case where stupid ideas should be make harder to implement. Otherwise you get the present web, where a lot of companies fetch all dependencies from GitHub every time their CI server wants to run a build.

About the only good thing that comes from this is that we get to laugh out loud every half a year when there's a random GitHub outage and those companies all scream bloody murder.

> The cost of a dependency for a good package manager is zero

The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.

I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.

That still isn't enough to refute "The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.". Sure, npm may be a bad package manager. If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. Most other ecosystems, with good or bad package managers, do not have tiny one-function packages -- it's possible to have an ecosystem not depending on it. If npm isn't good enough to have zero-cost dependencies, then your ecosystem should definitely not depend on tiny packages. This may be NPM's fault, but it's the fault of the ecosystem too.

For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.

> If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was.

That's great, and my point was that with a good package manager, that cost is effectively zero.

> And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken.

Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory.

Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.

> my point was that with a good package manager, that cost is effectively zero.

yes, which doesn't refute pdkl95's point. If you're not in the world with a good package manager, you should consider the cost of the dependency. The Node ecosystem seems to not have done that. That's the bottom line here, if there is a cost to dependencies (which you don't seem to disagree with, at least wrt NPM), then you shouldn't have dependencies for 11-line functions. Everything else is orthogonal.

It's not fully mutable. You can't change the code of a particular version, for example. The particular problem with left-pad was that npm is mutable in one way: deleting packages.

no this is the fundamental engineering issue... there is no magically mythical perfect package manager, and even if one exists there is a real intrinsic cost to adding a dependency. It is not a huge cost... it is minor... but the benefit of using a one line package is also minor... so when you are making a minor trade off over and over again as with npm where its not unsually to end up depending on 1000s of packages... then this is not a trade off that should be made without thinking...

just saying be an engineer. weigh the costs

I never said perfect, I said good. Some basic properties are that upstream changes don't break downstream dependents if you've protected against automatic version updates.

And yet, automatic version updates seem to be the first thing people bring up in defense of package managers when I mention that I generally think they're a poor strategy.

It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.

> The cost of a dependency for a good package manager is zero

I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell

That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.

>The cost of a dependency for a good package manager is zero

Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...