The Central Go Modules Repository

is coming soon!

 

GoCenter Screenshot
JFrog GoCenter is the first-ever central repository for Golang modules.

Say goodbye to re-packaging and re-validating public Go modules from source.

Say Hello to the new place for “go-getting” immutable modules that anyone can use!

 

GoCenter Screenshot
Be the first to try it! We'll email you as soon as it's live!
Your email will only be used for notifications about the release of GoCenter.

Curious to know more?

Here are some of the frequently asked questions:

We don’t use modules, we use vendoring

With the introduction of Go Modules in Go 1.11 the community is adopting a different approach. The dependencies are now cached on your computer are binary archives of the source files and should not be checked into the source control. Instead, go now resolves missing dependencies directly as binaries or as sources which are packed into binaries before they can be used as dependencies.

If vendoring is working for you at the moment, you do not need GoCenter.

Everything works without GoCenter, why do I need it?

Current resolution of modules uses git clone command to fetch the module archive if it exists, or the sources if it is missing (most of the libraries today don’t distribute a pre-packaged archive). Not only git clone is not optimized for massive concurrent downloads by CI servers across the world, packaging modules from scratch on the client every time the module is needed is time-consuming. GoCenter distributes pre-packaged immutable modules over HTTP.

OK, it’s faster, any other benefits?

Two additional benefits provided by GoCenter is immutability and persistence.

How GoCenter guarantees persistence and immutability?

While a GitHub author can remove the module in any time, destroying your build reproductivity, a pre-built artifact of the dependency will remain cached in GoCenter. GoCenter is a source for immutable modules, provided by their authors. We make sure that once the module is added to GoCenter, its metadata and the content of the binary archive won’t change, and you will always consistently get the same binary for the same request.

Won’t a central repository create a single point of failure? What happens if it is not available or out of business?

GoCenter doesn’t host any unique content. You can switch to another source of dependencies in any time by only change the value of GOPROXY environment variable.

How modules get into GoCenter?

While we made sure that the most popular modules are already there, anyone can request a module inclusion. As long as the module has an open source, an OSS license and popular enough (stars threshold on GitHub), its sources will be automatically downloaded, packaged and made available for use. The same process will be applied to this module’s transitive dependencies, making sure all the dependency graph can be successfully resolved from GoCenter.

How are modules in GoCenter licensed?

We respect the original license and copyright; generated go metadata files are under the MIT license.

Why immutability is important and don’t GitHub tags provide it?

Immutability is important since having immutable dependencies is the only way to guarantee a reproducible build. If you aren’t sure that module A version 1 is the same artifact today as it was six months ago, you can’t be sure that the code dependent on it behaves the same. Unfortunately, GitHub can’t provide immutability guarantees for at least two reasons:

  • GitHub allows force-pushing content to an existing tag, removing the immutability promise of a tag.
  • Also, if an author removes a project from GitHub, someone else can create another project under the same name and release binaries under same coordinates, but with completely different content.
It makes sense, but doesn’t a repository like JFrog Artifactory or Athens achieve the same benefits?

Once we step away from vendoring, we are dealing with a hierarchy of caches, each having their pros and cons:

  1. Local cache: Exists on your computer. Provides immediate access. Not shared. Not reliable (can be wiped at any moment).
  2. Organizational cache: JFrog Artifactory or Athens. Provides faster (Intranet) access. Provides reproducible builds as it caches the dependencies used once for build reproduction. Requires team infrastructure. Requires effort to get modules into the cache and maintain them (cleanups, backups, availability).
  3. Public cache: GoCenter. Provides fast access. Provides reproducible builds as it caches the popular and requested dependencies from version control. Highly available, requires no maintenance from the user and free to use.

Since each one of the layers serves a different purpose for different scenarios, JFrog Artifactory or Athens are not a replacement for GoCenter.

Ok, but I don't want to pay or to learn a new tool!

GoCenter is free and does not require any action apart of setting the GOPROXY variable. Once set, your builds are now faster and reproducible.

I heard that Google is planning to offer a central repository for Go Modules. How does GoCenter fit into that?

Google has announced plans to introduce a central Go Modules repository (“Google-run module mirror”) in August, 2019. Like JFrog GoCenter, this service (will) pull modules from original sources and will package and serve them as immutable, trusted modules. We’re excited to see Google acknowledge the pain points that JFrog is currently solving for the community with GoCenter and JFrog Artifactory. Google also plans to offer concrete APIs and surrounding services around Module Mirrors, including a public feed for new modules. We look forward to working with Google and other vendors to integrate these services into GoCenter once they become available, and to continue to improve the ecosystem of public, trusted Go modules.