> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this.
But that specific incident had nothing to do with using a VCS for packages? He removed left-pad from npms index, the code behind it was still online. Or did you mean more generally in a "single point of failure/removal" sense?
When you have a system where an individual can remove one item in a vast dependency tree where no one has central oversight you create risks like this. This also says a lot about relying on external dependencies like there is no tomorrow, but the point is still valid. I can imagine a thousand ways to break a system like this.
Apart from that, version control systems are optimized for controlling versions, not delivering static content.
I'd rather you answered the question instead of dodging it. However here are a few off the top of my head, I'm sure there are many more reasons for it and reasons against, but that is why I asked in the first place.
- There are several popular, well maintained, hosted VCS providers, such as GitHub, who have good bandwidth, and host open-source projects for free. Nice as most open-source projects are unfunded.
- A VCS gives you traceability in what's changing in your package repository 'for free' - nice when you open it up to contributors.
- A git-based package repository can be kept locally in relatively little space, allowing for the case where the package repo host goes down - I've had issues with being unable to install from PyPI in the past because it's down, I have not had that issue with git-based repositories, for example (not a perfect comparison).
- A VCS based repository can aid in creating a system where a given state of the repo is consistent, and works together, and can be upgraded atomically. Stackage is doing something like this, providing a known working set of packages at any given release (although I'm not sure if they are backing that concept with a VCS).
Remember leftpad!