The official dependency management system Go Modules have been supported since Go 1.11, and has since exploded in use. As of 2020 of the adoption of Go Modules has risen to 82% among developers.

Brief Background

Before Go Modules were a thing, there was a variety of community-created dependency management systems such as dep, godep, and govendor. All of these tried to solve the issue of managing the package versions used in applications.

You might not even have heard about $GOPATH, but this used to be something every Go developer had to wrap their heads around. $GOPATH is the path to the location of your workspace, all of your code had to live within this space before Go Modules. That meant that you weren't able to put your code anywhere you wanted, Go Modules changed all of that and now allows developers to place their code wherever they please as long as they have a go.mod file in the directory.

Go Modules

One of the first things you want to do after creating a folder or repository for your new project is to name the module. You typically name it the same as the path to your repository, such as: github.com/johan-lejdung/my-repo but you are free to name it whatever you want.

You create the module with the following command

go mod init github.com/johan-lejdung/my-repo

After you've run the command there is a go.mod and go.sum file in your repository, in the interest to keep this article brief feel free to read more about these two files over at this post.

The beauty of Go Modules is that you won't have to update the dependencies yourself, most built-in Go commands will automatically update the dependencies in your code as you run it. So whenever you build, run or fetch a package it’s all updated automatically.

Read more about Go Modules here.

Private Repositories

If you have your code in a private repository you might have issues accessing it and are presented with errors such as 410 Gone. Go 1.13 introduced a new environmental variable $GOPRIVATE .

From: tip.golang.org

The GOPRIVATE environment variable controls which modules the go command considers to be private (not available publicly) and should therefore not use the proxy or checksum database. The variable is a comma-separated list of glob patterns (in the syntax of Go's path.Match) of module path prefixes. For example,

GOPRIVATE=*.corp.example.com,rsc.io/private

causes the go command to treat as private any module with a path prefix matching either pattern, including git.corp.example.com/xyzzy, rsc.io/private, and rsc.io/private/quux.

To be able to access your private repository you will need to set your $GOPRIVATE with the following command:

go env -w GOPRIVATE=github.com/repoURL/private-repo

You can also include all repositories under an organization or provide a comma-separated list of individual repositories.

go env -w GOPRIVATE=github.com/<OrgNameHere>/*

If you are using SSH to access your Git Repository you should consider adding the following to your ~/.ssh/config file to enable the Go command to access the git service:

Host github.com
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_github

Where ~/.ssh/id_github is the private key for your SSH authentication. The same setup should work with other repositories such as Gitlab and Bitbucket.

If you are using SSH to access a local Git Repository you should add the following to your ~/.gitconfig

[url "ssh://git@git.local.intranet/"]

       insteadOf = https://git.local.intranet/

I hope you have enjoyed this mini-guide. For updates on new articles and content from me, follow me on twitter @JohanLejdung.