Hacker News new | comments | show | ask | jobs | submit login

The same can happen with GitHub repositories, though, that is how the vast majority of Go packages get published.

It's almost as if privately controlled, centralized archives are a bad idea.

1. However, it would deal with GP's problem - that is, that somebody else could upload a package with the same name as one of the ones removed and cause ... surprises the next time someone runs npm install.

Github repos are namespaced to their owners, at least, radically reducing the potential for this kind of thing.

2. /s/github/whatever . As long as there's a public URL from which something can be cloned, the idea still works, as long as that URL doesn't someday point to something completely different. Again, not impossible, but less likely than with NPM.

3. There are, like it or not, real advantages to centralised archives - discoverability, optimisation of dependency resolution, etc. 'Privately controlled' is an elastic idea - it seems to me that there's a difference between a non-profit foundation, say, and a for-profit company like NPM or GH, but both are 'privately controlled'. The question is whether these advantages outweigh the disadvantages. In my opinion, they do.

About your third point, discoverability and optimization of dependency resolution can be solved by a proxy, in a decentralized system, like the one used in Go.

IPFS with public keys per developer and signing of packages would solve that.

Except Go isn't GitHub specific, I could use BitBucket, Gitlab, or any service I setup myself. Even locally, just like git itself I suppose. Go supports other tools like Mercurial as well as others.

Hasn't hurt Java devs any. Although we have plenty of mirrors and no concept of unpublishing.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact