Help with go modules

[crashkid]

My team has been developing Kubernetes operators for the last year in Go. Like everyone else, we’ve had no shortage of go mod frustration. Long story short, we are using go 1.12 and go modules. (it’s the closest we can get to get everything working - CI/CD, IDE’s, etc…)

I was just curious how you guys approach simple stuff like this.

I’m developing an app in Go. At the same time I’m writing a utility library that application will use.

Thus, in my app:

import "github.mycompany.com/myuser/somerepo/mylibrary"

So I do some work, commit the changes to my library, push and merge.

Back in my app I write some code to use the new changes in my library and then I do a fresh “go mod download” and try and compile my app and it doesn’t see the changes in my library.

So I completely purge my go cache. (rm -rf ~/go/pkg). I “go mod download” again. I confirm my library is downloaded.

Same problem.

Can someone help me understand how Go module interacts with Git? The documentation is TERRIBLE.

How do people approach doing this? What a frustrating module management design.

[NobbZ (Norbert Melzer)]

Modules lock your dependencies to a commit hash, iirc it’s in the go.sum.

You should be able to update by deleting it, it by removing the line about your dependency. Also there is probably a command which unlocks currently pinned deps.

[hollowaykeanho (Holloway)]

@crashkid

Can someone help me understand how Go module interacts with Git? The documentation is TERRIBLE .

Go module treats master branch as release branch with git tag as point release. As you git commit and release to master branch, you need to tag it with semantic release format with v in front (e.g. v.1.0.0).

Then, your go.mod will have a clean and nice require clauses. E.g.:

require (
        github.com/company.com/myuser/dep1 v1.2.3
)

---

@crashkid

How do people approach doing this? What a frustrating module management design.

Normally right before the release commit (as in, checking in release documentation, artifacts, etc), I’ll do a “module refresh” step on my development side. That means:

1. delete the go.sum file.
2. audit the require clauses in go.mod
3. run a full test suite: $ go test <all kinds of arguments> ./...
4. check both go.mod and go.sum.
5. commit this changes as dependency audit.
6. proceed to release commits.

This is done by the release developer (the big guy that signs the release) and should always be a single commit.

---

For simultaneous library and app development, go.mod is the right way, using the replace clause. Someone asked this before so you can refer to there: Go modules - use what is checked out

In your case, the replace clause should replace github.my/company.com/myuser/somerepo to something else.

---

@crashkid

The documentation is TERRIBLE .

The documentation is very clear: Modules · golang/go Wiki · GitHub. In fact, it is too clear and long that it causes confusion and get someone lost in the text jungle.

What I did was to make good use of the table of contents to find what I need, while having some sandbox repo to experiment out the topic of interest.

---

go.mod is in fact quite flexible and powerful than the classical mechanisms. It allows you to develop outside GOPATH and using the conventional git method instead. The direction is not to use GOPATH in the future (but it’s a long way there).

comparing to the past, vendoring and single directory GOPATH was very painful. It was so painful that I nearly quit ramping Go.