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.
Top comments (3)
"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."
If you are going to host the module on a repository the module name in go.mod has to be the same as the repository url:
groups.google.com/g/golang-nuts/c/...
The only exception is if you setup a server running on port 80 somewhere which contains a tag pointing to the repository where your code is then you can use the url of your server in the module name instead. But the module name has to be a correct URL in either case.
This will be a big help to developers who are using a git repo on a private server (192.168.xxx.yyy or 10.xxx.yyy.zzz) without a github or other web server fronting the repo. There's almost no documentation for this case and there are a couple things you have to do that are not obvious.
Here's a (longer) write up I did to document the necessary steps:
stackoverflow.com/questions/606458...
Kudos for you :D