Skip to content
This repository has been archived by the owner. It is now read-only.
master
Go to file
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

gps
Build Status Windows Build Status Build Status Codecov GoDoc


gps has moved into dep - this repository is no longer maintained.

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.

Wait...a package management library?!

Yup. See the rationale.

Features

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.

Non-Choices

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 = 1 set
  • 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 vendor directory
  • A manifest and lock approach to tracking version and constraint information
  • Upstream sources are one of git, bzr, hg or svn repositories
  • 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)
  • 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/* or my_company/* are handled)

Choices

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.

This list may not be exhaustive - see the implementor's guide for a proper treatment.

Contributing

Yay, contributing! Please see CONTRIBUTING.md. Note that gps also abides by a Code of Conduct, and is MIT-licensed.

You can’t perform that action at this time.