Frequently Asked Questions

Have more questions about GoCenter? We probably have the answer!

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 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. We truly believe it's the right way to do things. Also, take a look at (this video)[https://youtu.be/KnuJnU35KBM?t=803] (the Why not Vendoring part of it, 3 minutes).

Saying that, if vendoring is working for you at the moment, you do not need Go Modules or GoCenter.

Everything works without GoCenter, why do I need it?

The current resolution of modules uses the 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 is git clone not optimized for massive concurrent downloads by CI servers across the world, but it’stime-consuming to package modules from scratch on the client every time the module is needed. GoCenter distributes pre-packaged immutable modules over HTTP.

OK, it’s faster, any other benefits?

Two additional benefits provided by GoCenter are persistence and immutability (see below ⬇️).

How does GoCenter guarantee persistence and immutability?

While a GitHub author can remove the module any time, destroying your build reproducibility, a pre-built artifact of the dependency will remain stored 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 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 at any time by changing the value of the GOPROXY environment variable.

How do modules get into GoCenter?

While we made sure the most popular modules are already in GoCenter, anyone can request a module inclusion. As long as the module is an open source, has an OSS license and is popular enough (meets the 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 the complete dependency graph can be successfully resolved from GoCenter.

How are modules in GoCenter licensed?

We respect the original license and copyright.

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

Immutability is important because 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.
• If an author removes a project from GitHub, someone else can create another project under the same name and release binaries under the same coordinates, but with completely different content.

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 other than 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.

I'm getting "verifying … checksum mismatch" errors. Why is this happening?

There are two options when you can get a "checksum mismatch" error:

1. The downloaded file is corrupt if you are a victim of a MITM attack. Check the dependency you're downloading to verify its authenticity.
2. You used GoCenter between January 29, 2019, and March 14, 2019, during which period GoCenter generated "smarter", non-empty mod files for the packages it built. While we still believe that was the right solution, the downside of it was an inconsistency with how the go client works (generating empty mod file). Because of this inconsistency, the checksums didn't match. If you favored the mod files generated by GoCenter, you'd experience the checksum mismatch with the mod files generated by the go client and with the modules downloaded from GoCenter after March 14th, 2019. In this case, feel free to delete the local go.sum file to let the go client generate a correct one. Here's the list of modules, for which GoCenter has generated non-empty mod files. Please use it as a reference to determine "non-suspicious" checksum mismatches.

Does GoCenter work globally?

Yes, you can get your Go modules from GoCenter no matter where you are in the world.

Why do I not see all of the tags of a given Go project?

GoCenter actively processes up to the latest 20 tags in the last year of a given Go module. In case the project has more than 20 tags (versions) in the last year, GoCenter may not necessarily have the tag that is older than the last 20. GoCenter eagerly fetches the public repository for requested modules that are missing from GoCenter, so once a user requests a particular version of a module, GoCenter will keep a cached copy of that module regardless of the version as long as it is publicly available.