Prepare for Modules (vgo support)

[the42]

This is a placeholder ticket to collect the various ideas and implementation steps currently discussing Golang module support.

A module is a collection of packages, denoted by a common filesystem root, in which in it's simplest form a file named go.mod resides. As a consequence there is no more need of GOPATH.

A proposal and reference implementation are under way.

For the design of go-mode a couple of questions come up like shall a future go-mode support both environments of set GOPATH and pure Golang module setups?

[dominikh]

For the design of go-mode a couple of questions come up like shall a future go-mode support both environments of set GOPATH and pure Golang module setups?

Yes, it should.

[kavirajk]

any update on this?

[seagle0128]

Any update please?

[psanford]

go-mode works pretty well for me when using modules. Are there concrete things that aren't working for people right now?

[dominikh]

Things that come to mind:

• go-packages-add won't work in a module environment; but it also doesn't work correctly in most GOPATH environments, anymore. I recommend deprecating the function and recommending people use goimports instead.
• we could add a major mode for go.mod files. It should be fairly trivial, needing only a very basic syntax table and simple indentation.
• We should check go-mode for code that expects a GOPATH. Some I've found so far:
  • go-set-project

[psanford]

We've added a new major mode for the go.mod file in 50e15c7

[dominikh]

We've deprecated all GOPATH-related functionality. Building projects using GOPATH is not expected to be supported by Go for much longer. go-packages-add should in theory work fine if setting go-packages-function to go-packages-go-list, but in reality, most people use goimports or gopls, anyway, and don't add imports manually.

go-mode has been working fine with modules for a while, so I think we can close this issue.