Goprox is a tool for managing your own Golang dependencies. Use it to:
- Curate dependencies for your whole organization
- Provide a server from which anyone can read and
go getdependencies on your
- Insulate your dependencies from changes upstream in Github/BitBucket
This project is alpha status. It's in early development and not all features are available. It is available for testing, however. See below for details.
Goprox is both a server and a client. The server,
goproxd, acts as a proxy for the
packages under your
GOPATH that everyone can access over the network. The client,
goprox is a convenient CLI that talks to
For example, if someone is running a
goprox server, you execute the following command
go get Gorilla Mux from it:
goprox get github.com/gorilla/mux HEAD
This command does the following:
goproxto package up the latest version (
$GOPATH/src/github.com/gorilla/muxon its filesystem
- Receives the package
- Unpackages it and puts the contents into
Since this project is in alpha, there are no downloadable binaries. To install it, you must have the following installed:
- Go 1.7+
- GNU Make
If you have those dependencies installed, simply clone this repository and run:
You will then have
./cmd/server/goproxd binaries available.
The former is the CLI and the latter is the server.
Why Goprox Beats
As you know,
go get github.com/gorilla/mux will download the latest version of
the code at https://github.com/gorilla/mux and install it directly into your
This approach is quick and easy, but presents the following problems:
- Your codebase may not compile later if the authors of Gorilla Mux change the code in an incompatible way
- Multiple Go projects might need different versions of Gorilla Mux, but there is only
one version in the
The second problem is solved by the
If you're unfamiliar with how the
vendor folder works, here is a brief overview:
gotoolchain will look for a directory called
vendorin the current directory as well as the directories above the current directory
- The toolchain will look for dependencies in the
vendordirectory first, before looking in the
- That fact means that you can "freeze" a dependency package's version for just your
project, without changing any other part of the
- Your project still has to be in the
- In most cases, Go projects put a single vendor directory at the project root
- The aforementioned tools (Glide and Godep) -- and others -- can automatically manage
vendordirectory for you
So, we already have tools to solve both of the above problems, so why do we need another?
Why Goprox Beats Glide, Godep and Other Tools
So, in order for these tools to fetch a dependency for use in your project, they have to go to the source control repository -- Github in most cases -- and download the code.
That means that the released packages -- the code you depend on -- lives in the same place as in-development code. That's a fundamental problem, because development, or "bleeding edge" code is meant to change over time, but your dependencies can't. If they did, your build will become unstable and your progress will come to a grinding halt.
Let's zoom in on some specific examples of this problem:
- You depend on version
e406d3aof a package on GitHub. Three weeks later, the package's developer does a big
git rebaseand squashes that commit into another. Since your dependency tools can't download the package at that version anymore, your builds break. Your only option is to somehow determine which new version is most appropriate to use
- You depend on a package in GitHub, and three weeks later it is deleted. Your build is broken and you have to hope that someone still has a copy of the package code
- You depended on a package in Google Code, then Google Code shut down. Just as with the previous example, your build is broken and you have to hope that someone still has a copy of the package code. See here for more details on how that shutdown affect Go projects specifically
Why Not Check In Your
If you're looking to fix the issues above, you could just check in your vendor directory! Nobody who builds your code will need to download any dependency management tools (Glide, Godep, etc...), nor will you risk your build breaking because you will have no external dependencies. Every dependency you need will be in your repository forever.
However, you'll eventually need to upgrade the code in your vendor directory, and then you're faced once again with the problems listed in the previous section.
Additionally, if you are writing a library yourself, or it's possible that someone might
import your code in the future, they themselves will run into problems importing and using your
package. See this thread for more
detail on why this is the case.