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