Thanks, though I don't think that will help us for our specific problem. gobin does not compile for <go1.11 (prior to os.UserCacheDir) so one Go version that we support will fail there without additional logic to guard against this. At the moment what we have is a git clone and a go install that work provided we shunt into GO111MODULE=off/auto or there is go.mod in the repo (which doesn't exist upstream).
Also an additional detail, the change that introduced this is 65c206[1], so I can see why it's happening. Perhaps the only way around it for us is to conditionally `go mod init || true` in testing to make sure there is a go.mod present (short of adding go.mod upstream which I have a PR for). Dan [1]https://github.com/golang/go/commit/65c2069a9f30cb6fa2c512d17dc0ad65 4d621da9 On Mon, 2019-03-04 at 14:13 +0000, roger peppe wrote: > It's not a standard tool, but you could use github.com/myitcv/gobin. > > > On Sun, 3 Mar 2019 at 20:56, Dan Kortschak <d...@kortschak.io> wrote: > > > > > As part of our testing we need to install a tool that currently > > does > > not have go.mod/go.sum files. Since we test on Go versions both > > with > > and without module support and want to test using modules on the > > versions that have module support we need to use an approach that > > works > > in both of those situations. We use git clone and checkout to get > > the > > version we want. > > > > However, this fails when GO111MODULE=on because go install wants to > > find a go.mod and does not. Note that the tool has no external > > dependencies. > > > > ``` > > $ mkdir -p /home/travis/gopath/src/github.com/goccmack > > $ git clone https://github.com/goccmack/gocc.git > > /home/travis/gopath/src/ > > github.com/goccmack/gocc > > Cloning into '/home/travis/gopath/src/github.com/goccmack/gocc'... > > $ cd /home/travis/gopath/src/github.com/goccmack/gocc > > $ git checkout 0e2cfc030005b281b2e5a2de04fa7fe1d5063722 > > Note: checking out '0e2cfc030005b281b2e5a2de04fa7fe1d5063722'. > > > > You are in 'detached HEAD' state. You can look around, make > > experimental > > changes and commit them, and you can discard any commits you make > > in this > > state without impacting any branches by performing another > > checkout. > > > > If you want to create a new branch to retain commits you create, > > you may > > do so (now or later) by using -b with the checkout command again. > > Example: > > > > git checkout -b <new-branch-name> > > > > HEAD is now at 0e2cfc0... Merge pull request #78 from > > shivansh/fix/Makefile > > $ go install > > go: cannot find main module, but found .git/config in > > /home/travis/gopath/src/github.com/goccmack/gocc > > to create a module there, run: > > go mod init > > ``` > > > > My approach to dealing with this is to set GO111MODULE=auto for the > > go > > install operation, but this is very kludgy and not guaranteed to > > work > > if GO111MODULE=auto/off is not respected in the future by one Go > > version (we support 3 minor versions of Go, so this could > > potentially > > happen). > > > > What is the recommended approach for this situation, assuming the > > tool > > authors do not want to add a go.mod file? > > > > -- > > You received this message because you are subscribed to the Google > > Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an > > email to golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
