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