search

myitcv / gobin

gobin is an experimental, module-aware command to install/run main packages.
BSD 3-Clause "New" or "Revised" License
219 stars 11 forks source link

Proposal: officially deprecate gobin as of Go 1.16 #103

Closed myitcv closed 3 years ago

myitcv commented 3 years ago

Apologies for being slow at getting round to raising this issue. Thanks to @howardjohn for raising #102.

Go 1.16 supports go install $pkg@$version to install commands without affecting the main module. This is the default mode of operation for gobin.

But another change in Go 1.16:

Build commands like go build and go test no longer modify go.mod and go.sum by default. Instead, they report an error if a module requirement or checksum needs to be added or updated (as if the -mod=readonly flag were used). Module requirements and sums may be adjusted with go mod tidy or go get.

means that changes are required in gobin for it (gobin) to continue to function when using cmd/go 1.16 (tests currently fail for example)

It's not clear to me however that it is worth making these changes (although I would be very open to someone else making the required changes). Whilst these Go 1.16 changes do not entirely cover the gobin use cases, go install $pkg@$version is generally sufficient.

Also noting the recently accepted proposal to support go run $pkg@$version, which should hopefully land in Go 1.17.

However, I'm raising this issue for discussion in case others disagree.

cc @rogpeppe @mvdan (and @mmcloughlin from a #tools message on Slack)

mmcloughlin commented 3 years ago

Thanks for raising this discussion. I have hit this issue in a couple of repositories so far:

https://github.com/mmcloughlin/avo/pull/166 https://github.com/mmcloughlin/addchain/pull/61

However in both cases I've been able to easily deal with it by switching to the preferred tools.mod solution. And once we get to Go 1.17 (and therefore don't have to maintain 1.15 behavior) I can just switch to the new go install behavior if I want.

So from my point of view I think deprecating gobin going forward is fine.

mvdan commented 3 years ago

I also agree that deprecating gobin is a good option right now. I seem to recall that Jay and others want to collect data and user reports on how they are affected by the limitations of go install path@version, but that can happen without the need of rewriting part of gobin.

myitcv commented 3 years ago

I've also added a note to the description that a proposal to support go run $pkg@$version was recently accepted and will hopefully land in Go 1.17.