This article is a pinch hitter for the 16th day of Go Advent Calendar 2020. Strangely, I decided to talk about Go 1.16 on the 16th day.
Go1.16 includes various updates for Modules. cf. https://tip.golang.org/doc/go1.16#tools
go install
to facilitate global installation of tools. In the future, the roles will be organized as " go install
for building and installing binaries "and" go get
for editing go.mod
". (The issue is here.)GO111MODULE
is on by default, which means that Module mode is always enabled. Say goodbye to GOPATH mode.go build
and go test
no longer automatically update go.mod
. Editing go.mod
is done by go get
, go mod tidy
, or manually.In this article, I will explain how to use go get
/ go install
after Go1.16, and points to keep in mind. By the way, the following explanations are based on Module mode, not GOPATH mode. (Otherwise it would be too complicated)
go install <package> @ <version>
for global installation of tools.go install golang.org/x/tools/gopls@latest
go get
will be removed in a future version.go get
will be organized as a command only for adding dependencies to go.mod
, but there are other ways to edit go.mod
than go get
. So, the chances of using go get
are likely to decrease in the future.Until now, the familiar go get
command has been used to install tools globally ($ GOPATH/bin
) in Go, but it had one problem. Since go get
also has the role of editing go.mod
, to install only the tool without touching go.mod
," go through the directory with go.mod
" " I needed to enable go.mod
on the tool side and do go get
. It is as follows when summarized in one.
$ cd $(mktemp -d); GO111MODULE=on go get golang.org/x/tools/gopls
I don't want to spend such a lot of time on installing it, and above all, I did go get
without knowing about Modules and unwillingly updated go.mod
. (Source is the author)
So, from Go 1.16 it looks like this:
$ go install golang.org/x/tools/gopls@latest
It was very refreshing.
** Actually, this format go install <package> @ <version>
is newly introduced in Go 1.16 **. This format consistently installs the specified version in $ GOPATH/bin
, whether under Module or not.
In Go1.16, GO111MODULE
is on by default, and go install
no longer edits go.mod
, so you don't have to worry about accidents.
@version
. Non-main packages are not subject to this format.go install <package>
without version specifiedgo install <package>
without @ version
outside the Module.@ version
(the version of go.mod
is reflected), but it takes a lot of work to describe the main package in go.mod
. Since it is (https://qiita.com/nirasan/items/2bdbf0ada7b4182d56ce), I think it is simple to do go install <package> @ <version>
even if it is under Module.go install
Other features of go install
, that is
$ GOPATH/bin
go install <package>
without specifying version)As for, it is the same as before. These are things that you can live without, but it may be useful to remember them once in a while.
go get
, go.mod
On the other hand, go get
transfers the role of binary installation to go install
and is organized as a command only for editing go.mod
. In releases after Go1.16 (scheduled for Go1.17), the function of binary installation by go get
has been removed, and all go get
s are equivalent to go get -d
, and the source is downloaded and go. The behavior will be just to add to mod
.
go.mod
Another change in Go1.16 was that go build
and go test
did not automatically edit go.mod
. Based on these, the method of handling go.mod
in Go1.16 is as follows.
go.mod
go get # no arguments
go mod tidy
go.mod
go get <package>[@<version>]
go.mod
I've listed four, but in reality, go mod tidy
covers all of them, so it seems that you can go with just one go mod tidy
.
As mentioned earlier, the automatic editing feature of go.mod
by go build
etc. will be disabled from Go1.16, so users up to Go1.15 will have go.mod
changed. But expecting go build
, what? May be. Let's do go mod tidy
.
Also, since Go1.17 or later will remove the function of binary installation of go get
, it seems that various procedure manuals and scripts need to be modified by then.
gopls
also has a change following Go1.16 from v0.6.0 that does not automatically edit go.mod
. Regarding the sequential development flow, I think that it will be arranged for new Modules.
There are some incompatible changes around the tool, but Modules from Go 1.16 are much simpler and less addictive, so I think it's easier to recommend to beginners. As a writer who has a strong desire to spread Go, the less addictive you are, the easier it will be to do it, and the more motivated you will be to spread it.
Besides, I can't wait for Go 1.16, which is full of features such as embed
and io/fs
. The release is scheduled for February next year.
Recommended Posts