To each their own, but please consider using the -v flag so you understand how
many packages are bring recompiled each time. It is very common for a Go user
to upgrade their Go version and find that compilation slowed down as the set of
packages compiled each time now includes many long forgotte
> Often, this involves incrementing the version [...]
If the process of saying "this binary is good to go, deploy it locally for
use" already involve more than go install, maybe you could also "deploy"
the binary to a different location than $GOPATH/bin . The benefit there is
that you can take
* Dave Cheney [170418 09:57]:
> > Apparently Dave Cheney says to prefer "go install" over "go build"[3],
> except when cross-compiling [4]. However, many of these posts are older,
> and Golang moves at such a rapid clip that it's difficult to keep track of
> what everybody is doing.
>
> This i
The good news is that Dave Cheney moves at that same rapid clip.
:-)
On Tue, Apr 18, 2017 at 6:57 AM, Dave Cheney wrote:
> > Apparently Dave Cheney says to prefer "go install" over "go build"[3],
> except when cross-compiling [4]. However, many of these posts are older,
> and Golang moves at suc
> Apparently Dave Cheney says to prefer "go install" over "go build"[3],
except when cross-compiling [4]. However, many of these posts are older,
and Golang moves at such a rapid clip that it's difficult to keep track of
what everybody is doing.
This information is still correct.
On Friday, 10
>
> Are there more that I'm unaware of?
>
go get. It downloads source and follows it up with go install.
Are some preferred in certain circumstances
>
The three ways you listed are similar but not equivalent, they have subtle
differences in behavior. Use whatever is a better fit for your needs
