Hrm, I don't consider this post to be insulting. It's a valid concern. Why do you think it's insulting?
We will eventually have an official package repository, but the idea behind Nimble's design is to be decentralised at its core, the official repo will just be another mirror for packages. Nimble uses Git/Hg so you can install from any Git or Mercurial URL. On GitHub, if you want to be sure that a package doesn't disappear, just fork it.
I assume OP is referring to the "leftpad" case, in which pulling one one-line package out of NPM caused hundreds of other NPM packages (and thousands of projects that built right off NPM) to stop working. This is a problem with NPM, not with package management in general - CPAN, CRAN, CTAN, Anaconda, PyPI and others have been active for years and even decades with no such mishaps.
Packages in any registry, however "real", can disappear because of security or legal reasons.
Nimble is way ahead of the game, in that hosting your own copy is a "git clone" away, and this should (in my opinion) be the recommended way to use it.
Packages in any registry, however "real", can disappear because of security or legal reasons.
The current registry requires merge approval to remove a package. This can be used to prevent "leftpad"-like disastrous takeovers.
I sometimes see hostile responses in nim-forum. I think it will not help expand the community.
In movies, theres often a part where the heroes struggle and go apart. I think this is a similar situtation. But like in the movies overcoming the struggles make the heroes stronger and win in the end. Of course this isn't a movie and the heroes might never overcome their obstacles and thus never win. But it's probably better if something is discussed, even if it's not in the best imagineable way, then not.
When one doing development with dependency packages, those will be cloned locally. Even if there's a chance of authors of those package suddenly deleting their packages, you can still do your development. It's not affected.
When there's change, handle it. It's like that too in another languages.
maybe we could do the same as done in dub (for D): eg https://github.com/dlang/dub-registry/blob/master/source/dubregistry/mirror.d
still decentrallized but allows for multiple mirrors; dub install foo will try different mirrors until the command succeeds. It helped stabilize installs as servers do go offline once in a while. eg:
registry at https://code.dlang.org/ (fallback ["registry at http://code.dlang.org/", "registry at https://code-mirror.dlang.io/", "registry at https://code-mirror2.dlang.io/", "registry at https://dub-registry.herokuapp.com/"])