gps
gps is the Go Packaging Solver. It is an engine for tackling dependency management problems in Go. You can replicate the fetching bits of go get, modulo arguments, in about 30 lines of code with gps.
gps is not Yet Another Go Package Management Tool. Rather, it's a library that package management (and adjacent) tools can use to solve the hard parts of the problem in a consistent, holistic way. gps is on track to become the engine behind glide.
The wiki has a general introduction to the gps approach, as well as guides for folks implementing tools or looking to contribute.
gps is progressing rapidly, but still beta, with a liberal sprinkling of panics.
Wait...a package management library?!
Yup. 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.
Assumptions
Ideally, gps could provide this shared foundation with no additional assumptions beyond pure Go source files. Sadly, package management is too complex to be assumption-less. So, gps tries to keep its assumptions to the minimum, supporting as many situations as possible while still maintaining a predictable, well-formed system.
- Go 1.6, or 1.5 with
GO15VENDOREXPERIMENT = 1set.vendor/directories are a requirement. - You don‘t manually change what’s under
vendor/. That’s tooling’s job. - A project concept, where projects comprise the set of Go packages in a rooted directory tree. By happy (not) accident,
vendor/directories also just happen to cover a rooted tree. - A manifest and lock approach to tracking version and constraint information. The solver takes manifest (and, optionally, lock)-type data as inputs, and produces lock-type data as its output. Tools decide how to actually store this data, but these should generally be at the root of the project tree.
Manifests? Locks? Eeew. Yes, we also think it‘d be swell if we didn’t need metadata files. We love the idea of Go packages as standalone, self-describing code. Unfortunately, the wheels come off that idea as soon as versioning and cross-project/repository dependencies happen. But universe alignment is hard; trying to intermix version information directly with the code would only make matters worse.
Contributing
Yay, contributing! Please see CONTRIBUTING.md. Note that gps also abides by a Code of Conduct, and is MIT-licensed.