gps is the Go Packaging Solver. It is an engine for tackling dependency
management problems in Go. It is trivial - about 35 lines of
code - to replicate the
fetching bits of go get using 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. It is a distillation of the ideas behind language package managers like
bundler, npm,
elm-package,
cargo (and others) into a library, artisanally
handcrafted with ❤️ for Go's specific requirements.
gps was on track to become
the engine behind glide; however, those efforts have been
discontinued in favor of gps powering the experimental, eventually-official
Go tooling.
The wiki has a general introduction to the gps
approach, as well
as guides for folks implementing
tools or looking
to contribute.
Yup. See the rationale.
A feature list for a package management library is a bit different than one for
a package management tool. Instead of listing the things an end-user can do,
we list the choices a tool can make and offer, in some form, to its users, as
well as the non-choices/assumptions/constraints that gps imposes on a tool.
We'd love for gps's non-choices to be noncontroversial. But that's not always
the case.
Nevertheless, these non-choices remain because, taken as a whole, they make experiments and discussion around Go package management coherent and productive.
- Go >=1.6, or 1.5 with
GO15VENDOREXPERIMENT = 1set - Everything under
vendor/is volatile and controlled solely by the tool - A central cache of repositories is used (cannot be
GOPATH) - A project concept:
a tree of packages, all covered by one
vendordirectory - A manifest and lock approach to tracking version and constraint information
- Upstream sources are one of
git,bzr,hgorsvnrepositories - What the available versions are for a given project/repository (all branches, tags, or revs are eligible)
- In general, semver tags are preferred to branches, are preferred to plain tags
- The actual packages that must be present (determined through import graph static analysis)
- How the import graph is statically analyzed - similar to
go/build, but with a combinatorial view of build tags (not yet implemented)
- How the import graph is statically analyzed - similar to
- All packages from the same source (repository) must be the same version
- Package import cycles are not allowed (not yet implemented)
There are also some current non-choices that we would like to push into the realm of choice:
- Importable projects that are not bound to the repository root
- Source inference around different import path patterns (e.g., how
github.com/*ormy_company/*are handled)
These choices represent many of the ways that gps-based tools could
substantively differ from each other.
Some of these are choices designed to encompass all options for topics on which reasonable people have disagreed. Others are simply important controls that no general library could know a priori.
- How to store manifest and lock information (file(s)? a db?)
- Which of the other package managers to interoperate with
- Which types of version constraints to allow the user to specify (e.g., allowing semver ranges or not)
- Whether or not to strip nested
vendordirectories - Which packages in the import graph to ignore (if any)
- What constraint overrides to apply (if any)
- What informational output to show the end user
- What dependency version constraints are declared by the root project
- What dependency version constraints are declared by all dependencies
- Given a previous solution, which versions to let change, and how
- In the absence of a previous solution, whether or not to use preferred versions
- Allowing, or not, the user to swap in different source locations for import paths (e.g. forks)
- Specifying additional input/source packages not reachable from the root import graph
This list may not be exhaustive - see the implementor's guide for a proper treatment.
Yay, contributing! Please see
CONTRIBUTING.md.
Note that gps also abides by a Code of
Conduct, and is MIT-licensed.