There's two distinct problems I see here, which probably plague most package managers:
1. Package naming: All the good names will be gone soon, which'll probably lead to big players trying to get package names of little players. Which will then result in broken dependencies a la left-pad. Afaik the latter has been solved in NPM [1]. The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.
2. The power of deps and our reliance on good will: When installing dependencies, we basically grant them the power to wreak any kind of havoc they want. The ways we mitigate the worst: Belief in the magical power of open source, mostly using libs that are popular (hence might've gotten a good read by an IT-sec person) and at enterprise scale some static analysis tools to get an idea of how it interacts with your system. I think we're in need of a technical solution at the package manager level, where a dependency has to explicitly ask for certain capabilities (similar to how Android apps work).
The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.
There's a point beyond which the desire for simplicity creates dangerous abstractions. A developer should expect to put more effort into installing deps than just remembering a package name.
Size does mean the scope of any issues with NPM is greater, but many of those issues seem unique to NPM's design and the extremely fine-grained nature of Node packages as a whole. One developer had a temper tantrum and unpublished one package and the entire Node universe caught on fire... that kind of catastrophic failure doesn't seem to happen elsewhere, even at a smaller scale.
True, that WAS a deficiency, though one that seems to be fixed now.
Given that dependencies are also resolved by name in the Ruby & Python I'd think there's no technical reason for why a similar thing wouldn't happen, is there?
Given that dependencies are also resolved by name in the Ruby & Python I'd think there's no technical reason for why a similar thing wouldn't happen, is there?
I don't know, I'm not familiar enough with those languages, but I would guess that if anything similar did happen, it would probably wind up posted here, although absence of evidence isn't evidence of absence.
It may also depend on implementation features besides package names - the worst that should happen if a remote dependency no longer exists is that future updates fail, but a local copy should always exist and the current build should still keep working. To me, vendoring dependencies should be the default.
Comments
There's two distinct problems I see here, which probably plague most package managers:
1. Package naming: All the good names will be gone soon, which'll probably lead to big players trying to get package names of little players. Which will then result in broken dependencies a la left-pad. Afaik the latter has been solved in NPM [1]. The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.
2. The power of deps and our reliance on good will: When installing dependencies, we basically grant them the power to wreak any kind of havoc they want. The ways we mitigate the worst: Belief in the magical power of open source, mostly using libs that are popular (hence might've gotten a good read by an IT-sec person) and at enterprise scale some static analysis tools to get an idea of how it interacts with your system. I think we're in need of a technical solution at the package manager level, where a dependency has to explicitly ask for certain capabilities (similar to how Android apps work).
[1] http://blog.npmjs.org/post/141905368000/changes-to-npms-unpu...
1) seems to plague NPM a lot more than others.
There's a point beyond which the desire for simplicity creates dangerous abstractions. A developer should expect to put more effort into installing deps than just remembering a package name.
That it plagues NPM more than others might be due to size, NPM has almost 3x as many packages as the next large module repository (Maven) [1].
[1] http://www.modulecounts.com/
Size does mean the scope of any issues with NPM is greater, but many of those issues seem unique to NPM's design and the extremely fine-grained nature of Node packages as a whole. One developer had a temper tantrum and unpublished one package and the entire Node universe caught on fire... that kind of catastrophic failure doesn't seem to happen elsewhere, even at a smaller scale.
True, that WAS a deficiency, though one that seems to be fixed now.
Given that dependencies are also resolved by name in the Ruby & Python I'd think there's no technical reason for why a similar thing wouldn't happen, is there?
I don't know, I'm not familiar enough with those languages, but I would guess that if anything similar did happen, it would probably wind up posted here, although absence of evidence isn't evidence of absence.
It may also depend on implementation features besides package names - the worst that should happen if a remote dependency no longer exists is that future updates fail, but a local copy should always exist and the current build should still keep working. To me, vendoring dependencies should be the default.