Go Modules in Go 1.11 rc1

Hello, as an early adopter, I have been running Go with GO111MODULE=on as a permanent setting, on the basis that it will become the default setting soon, so I might as well get used to it now.

Some Github based packages seem to play very well with Go Modules. Go get works although it seems to download to ~/golang/pkg/mod/github.com/<repo> rather than ~/golang/src/etc...

Other packages do not play well at all. Some give the error go: cannot find main module; see 'go help modules'. This error seems to be solved by running go mod init. The only problem is that this leads to a chicken and egg situation because if the go get has not yet happened, then where are you supposed to run the go mod init. Choosing a parent folder to run the go mod init is not satisfactory because it will inevitably lead to tons of dummy go.mod files littering the file system.

So, some questions then:

  • Should I retreat from the bleeding edge and stick to GO111MODULE=auto for now? Whereabouts should I run my go get commands?
  • If I run them at ~ this is outside of $GOPATH, with auto will this behave differently from say ~/go?
  • If I stick with GO111MODULE=on, what is the recommended way to get go code from github or other repositories?
  • An early article by Dave Cheney, in the days of vgo showed him using git clone followed by a go mod init and avoiding go get altogether. Surely this cannot be the recommended route?

Like I say, when Go Modules works, it does so really nicely. When it doesn’t it appears to defy all logic, and it seems that there is not nearly enough documentation to cover the problems that people are inevitably going to get.

I’d welcome the thoughts of more knowledgeable gophers. I’m sure you’re out there!

@rsc Any thoughts?

I believe using go get to install main packages is not yet implemented, but is on the road map. I base this on this issue thread: https://github.com/golang/go/issues/24250#issuecomment-377553022

Looks like you are correct. From the point of view of applying the principle of least surprise for the punter, this could have been handled a whole lot better, in my view.

Yet I’m sure that I have used go get for some packages.

Could they have been non-main packages?

Are you saying that go get would only work for non-main packages?

Sort of. At the moment, with Go 1.11 rc1 in module mode, go get needs a go.mod file to work. So if you are working in a project with a go.mod file and you need to add a dependency on a library package (a non-main package), or update a library package you’re already using, then go get <package> works nicely. It finds and downloads the requested package and updates the project’s go.mod file with a require spec for the package’s module.

On the other hand, if you’re trying to download, compile, and install a main package that someone else wrote and published on github.com or the like—something we’ve all been doing with go get for several years—that doesn’t work very well in module mode with Go 1.11 rc1. There’s a bit of a chicken and egg problem. go get wants a module file, but it won’t have one until it gets the module of the package you’re trying to get.

In the issue comment I linked above, @rsc states pretty strongly that go get needs to support installing main packages without a pre-existing go.mod file “eventually”, but goes on to express several open questions about the details of the implementation.

In other words. It is a feature they intend to implement, but it’s not there in 1.11 rc1.

Ah! I understand now. Thanks, Chris, for a very well laid out explanation!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.