Yes I think defaulting to go get -u without modules is best too.
Because modules allow version compatibility, and so code intended for use
with modules may not work at the repo HEAD, asking go get to fetch without
building may be more reliable.
Best,
Scott
On Monday, 10 September 2018
>> GO111MODULE=off go get -u github.com/my/package
>
> Last time I check, if GOPATH is unset and GO111MODULE is on it will download
> the source code to $HOME/go.
If you saw this behaviour then that is a bug. Or did you mean
GO111MODULE=auto or GO111MODULE is unset (in addition to GOPATH being
On Mon, 10 Sep 2018, 16:00 Paul Jolly, wrote:
>
> GO111MODULE=off go get -u github.com/my/package
>
Last time I check, if GOPATH is unset and GO111MODULE is on it will
download the source code to $HOME/go.
--
You received this message because you are subscribed to the Google Groups
This sort of "global" get/install is being discussed in
https://github.com/golang/go/issues/24250 (which will also cover the
documentation point). It's marked as "release blocked" for Go 1.12.
For now, I think the best approach is to:
GO111MODULE=off go get -u github.com/my/package
i.e. drop
What's the best substitute for "go get my/tool" in a modules world?
I used to be able to tell my users to set up Go with a GOPATH workspace and
then run "go get -u github.com/my/package". I can't find an equivalent
workflow now. The closest I can find is
GOBIN=~/bin GO111MODULES=on go get
