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!
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.
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.