3 ms·

Because a centralized repo is a disaster.

wlll 8y ago
As someone who has programmed a number of languages and currently mostly programs either Ruby or Go I have to say I would greatly prefer a Rubygems/bundler type system to the one Go seems to be heading for.
ofrzeta 8y ago
Why? It has worked out quite well for pretty much every other ecosystem like CPAN, PyPI, Maven etc. don't you think?
- Yokohiii 8y ago
  It worked out for the time being, but npm destroyed the illusion. I don't even see the problem. A package manager could rely completely on git with the advantage to not have an single authority that isn't giving a flying fuck about quality and security of the hosted packages. Yes it forces you to dig out a good package, evaluate it and look at the track record of the devs. Someone has to do it, but it is currently hardly happening.
BillinghamJ 8y ago
Have you ever noticed that 99%+ of Go libraries are pulled from Github?
- Yokohiii 8y ago
  Do they rely on github or on git? But it hardly matters. Github is an centralized interface to git, but the repos themselves are not centralized.
  - ofrzeta 8y ago
    Either you or I don't understand. Of course Git is a decentralized VCS but how would you make use of a software module without offering a repo on some server? As someone remarked in answer to another of your comments: Github is centralized as well - but it's doesn't specialize in offering versioned binary artifacts for ease use in a software project.
    - dvlsg 8y ago
      And if you rely on one of my packages and I delete it from github or make it private, your build stops working, right? Everyone was up in arms about npm allowing this a few months back. Rightfully so, I think, but I feel like it's going to be easy to hit this issue when pulling straight from github.
  - wild_preference 8y ago
    I don’t understanding the distinction you’re making. Most package managers I’ve used can point at mirrors. Even NPM can point at arbitrary local git branches, file paths, and remote locations. So “centralization: bad, git: good” seems like an irrelevant point.

wlll 8y ago

As someone who has programmed a number of languages and currently mostly programs either Ruby or Go I have to say I would greatly prefer a Rubygems/bundler type system to the one Go seems to be heading for.

ofrzeta 8y ago

Why? It has worked out quite well for pretty much every other ecosystem like CPAN, PyPI, Maven etc. don't you think?

Yokohiii 8y ago
It worked out for the time being, but npm destroyed the illusion. I don't even see the problem. A package manager could rely completely on git with the advantage to not have an single authority that isn't giving a flying fuck about quality and security of the hosted packages. Yes it forces you to dig out a good package, evaluate it and look at the track record of the devs. Someone has to do it, but it is currently hardly happening.

BillinghamJ 8y ago

Have you ever noticed that 99%+ of Go libraries are pulled from Github?

Yokohiii 8y ago
Do they rely on github or on git? But it hardly matters. Github is an centralized interface to git, but the repos themselves are not centralized.
- ofrzeta 8y ago
  Either you or I don't understand. Of course Git is a decentralized VCS but how would you make use of a software module without offering a repo on some server? As someone remarked in answer to another of your comments: Github is centralized as well - but it's doesn't specialize in offering versioned binary artifacts for ease use in a software project.
  - dvlsg 8y ago
    And if you rely on one of my packages and I delete it from github or make it private, your build stops working, right? Everyone was up in arms about npm allowing this a few months back. Rightfully so, I think, but I feel like it's going to be easy to hit this issue when pulling straight from github.
- wild_preference 8y ago
  I don’t understanding the distinction you’re making. Most package managers I’ve used can point at mirrors. Even NPM can point at arbitrary local git branches, file paths, and remote locations. So “centralization: bad, git: good” seems like an irrelevant point.