How GoCenter Connects Go Modules Authors With Consumers

UPDATE:As of May 1, 2021 – GoCenter central repository has been sunset and all features deprecated. For more information on the sunsetting of the centers read thedeprecation blog post

There’s no longer any doubt, Go modules are an accepted part of Golang. The over 300,000versioned Go modules in JFrog GoCentershows how they have been embraced for package management by the Go community. WithGo modules now enabled by default in Golang 1.13, the number of publicly available modules will grow even more rapidly — and some of them may be contributed by you.

But once you share a Go module project with the community, what happens to it? Does it get used? We would all like our projects to become as useful and popular astestifyorlogrus, but how can you know?

When Go module authors know who is consuming their modules, what versions are more popular and within what domains, they can make better decisions. Authors can collaborate together to improve aspects like testing. Authors can engage with the consumers of their modules to discuss new features or design.

This is something that we always had in mind when we were designing the UI of the GoCenter publicGOPROXY. GoCenter helps you to findversioned modules in its central repository,and also to know more about them once you do.

Using Used By for Go Packages

Search for a module in Gocenter, then view its modules page. Click theUsed Bytab.

The GoCenter UI shows every Go module version in GoCenter’s repository that uses the module.

Counting Downloads from GoCenter

TheUsed Bytab tells you how widely your modules are being referenced by other modules. But how deep an impact is it really making? Click the newMetricstab to see further statistics on the module, including the number of downloads of it were delivered each week.

How It Works

Now let’s talk about how GoCenter identifies these relationships. Building a version-to-version module relationship is not straightforward. This applies to both dependencies and ancestors in aUsed Bygraph.

For projects that have already adopted go modules, building a version-to-version module relationship is easy since the dependency versions are locked down in a `go.mod` file. However, that’s not the case for the majority of open source projects written in Golang.

For projects that adopted other dependency managers such asglideorgodep, the version-to-version module relationship can be captured via `go mod init` since this command also generates a `go.mod` file with dependency versions locked down.

In the example above, TheHelm package manager for Kuberneteshas not adopted Go modules yet but since they usedep, GoCenter builds the version-to-version module relationship usinggo mod init.

The challenging part is what to do when an open source project written in Golang doesn’t use any dependency manager, so there is no fixed versioning. In such scenarios, GoCenter runs `go mod tidy` (to explain in a very simple way) and captures the dependency versions along with the timestamp of when GoCenter ran this command. The timestamp helps GoCenter track the version-to-version module relationships as they change. GoCenter highlights this in the UI under theMod Filetab as shown in the example below:

The Power of the GoCenter Public GOPROXY

GoCenter is a public GOPROXY for open source Go modules that canhelp you accelerate builds of your Go apps. But it’s also a vital tool for telling you about those Go modules, and the relationships they have to each other. If you’re an author of Go modules, knowing who is consuming your projects can provide insights that can help your work, and that of the Go community, to continually improve.