8 ms·

"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, cou

by deong 11y ago

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

naasking 11y ago
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.
- efaref 11y ago
  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.
  - icebraining 11y ago
    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.
    - naasking 11y ago
      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.
    - stcredzero 11y ago
      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.
      - smarks 11y ago
        Exactly. That's the No True No True Scotsman Fallacy Fallacy.
        TeMPOraL 11y ago
        Compare also with Fallacy Fallacy - just because the argument is fallacious, doesn't mean the overall point is wrong.
        stcredzero 11y ago
        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.)
- coldtea 11y ago
  And wait till you hear what a sufficiently smart compiler can do! http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler
  - Bjartr 11y ago
    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.
    - coldtea 11y ago
      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...
- deong 11y ago
  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.
gipp 11y ago
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.
pfooti 11y ago
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.
- takno 11y ago
  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.
  - pfooti 11y ago
    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.
superuser2 11y ago
You could, and that's why it's trivial package manager hygiene to pin versions and always test before upgrading versions.
- TeMPOraL 11y ago
  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.

by deong 11y ago

naasking 11y ago

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.

efaref 11y ago
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.
- icebraining 11y ago
  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.
  - naasking 11y ago
    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.
  - stcredzero 11y ago
    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.
    - smarks 11y ago
      Exactly. That's the No True No True Scotsman Fallacy Fallacy.
      - TeMPOraL 11y ago
        Compare also with Fallacy Fallacy - just because the argument is fallacious, doesn't mean the overall point is wrong.
        stcredzero 11y ago
        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.)
coldtea 11y ago
And wait till you hear what a sufficiently smart compiler can do! http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler
- Bjartr 11y ago
  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.
  - coldtea 11y ago
    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...
deong 11y ago
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.

gipp 11y ago

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.

pfooti 11y ago

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.

takno 11y ago
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.
- pfooti 11y ago
  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.

superuser2 11y ago

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

TeMPOraL 11y ago
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.