Project Athens: The Components
Hi Gophers! Today continues the project Athens series.


If you don’t remember, Athens has two components:
- A registry server that serves public Go packages and sources the code from Github and other VCSs
- An edge proxy for folks to run to serve their private code
The tl;dr that explains those above two components is that if you do this:
vgo get github.com/arschles/assert
You get thegithub.com/arschles/assert package from Athens, not directly from Github. Athens got it from Github, but it stores the package in its own place.
And before I go on, a shameless plug to get involved:
If you wanna get involved, we have lots going on! Join us in the #athens channel in Gophers slack or for a weekly dev meeting (every Thursday, 11am Pacific time). There are tons of other ways you can get involved here.Athens the Project
Athens is actually the name of the project that contains two parts:
- The registry
- The proxy
These components play different roles in serving up hot, fresh Go packages for you.
The Registry
The registry is a central server for public Go packages on Github and other VCSs. As I write this, the way you would talk to the registry is to set your GOPROXY environment variable to point it to the registry server.
After you do that, your vgo get github.com/arschles/assert@v1 calls will hit the registry to get the package. If the registry doesn’t have the package, it’ll return a 404 Not Found and vgo will fall back to Github.
But wait, there’s more!
The registry will grab the package from Github in the background, so next time anyone does a vgo get github.com/arschles/assert@v1 call, the package will be there. That’s how the registry will grow (there are other ways planned, but I’ll go into them another time)
And one last important thing.
The registry will be public, central and freely available to Gophers. We don’t intend to make it “owned” or controller by any single company or group of people. I will have more details on how we’re going to make this happen, but here are some general principles we’re going to follow to make sure this happens:
- The registry is gonna be hosted by multiple companies
- It’s designed to share data across each company’s cloud (here is how)
- It sources its code from Github and other VCS’s and stores them in pluggable storage
- We are working hard to get a diverse set of folks involved in our community (that’s why I made my shameless plug above 😃)
The Proxy
The registry stores public code. Most of the time, it’s probably fine to pull public packages from there. The proxy comes into play when you want to either serve private packages or cache packages from the registry or some other source, including your internal VCS.
We’re working on making the proxy really simple to configure and run, so that anyone can really easily run the thing wherever and whenever they want.
If you’re familiar with the Java world, the registry is a little bit like Maven central and the proxy is a little bit like running your own Maven proxy with Artifactory or something similar.
Proxies also have more “enterprisey” functionality like exclude and include lists, and we’ll build more as we go and hear from folks what they need.
That’s it!
Keep on rockin’
— Aaron