Rationale

Why, oh why, would you write a package management library?!?

Because it's what the Go ecosystem needs right now.

There are scads of tools out there, each tackling some slice of the Go package management domain. Some handle more than others, some impose more restrictions than others, and most are mutually incompatible (or mutually indifferent, which amounts to the same). This fragments the Go FLOSS ecosystem, harming the community as a whole.

As in all epic software arguments, some of the points of disagreement between tools/their authors are a bit silly. Many, though, are based on legitimate differences of opinion about what workflows, controls, and interfaces are best to give Go developers.

Now, we're certainly no less opinionated than anyone else. But part of the challenge has been that, with a problem as complex as package management, subtle design decisions made in pursuit of a particular workflow or interface can have far-reaching effects on architecture, leading to deep incompatibilities between tools and approaches.

We believe that many of these differences are incidental - and, given the right general solution, reconcilable. gps is our attempt at such a solution.

By separating out the underlying problem into a standalone library, we are hoping to provide a common foundation for different tools. Such a foundation could improve interoperability, reduce harm to the ecosystem, and make the communal process of figuring out what's right for Go more about collaboration, and less about fiefdoms.