On Friday, June 4, 2021 at 6:24:28 PM UTC+2 Jacob Vosmaer wrote: > On Thu, Jun 3, 2021 at 6:35 PM Manlio Perillo <manlio....@gmail.com> > wrote: > > One possible solution is to have a GOENV file in the root directory of a > repository. > Thanks Manlio. Is that something that is possible now, or a feature > suggestion? From what I can tell it's not possible now. > > It was only a suggestion. I don't know if the Go team is willing to add additional complexity to the go command.
> What is possible already, now that I think about it, is for us to ask > our contributors to run 'go env -w GOFLAGS=-mod=mod'. It's not > something I would recommend in general because by the time you run > into a problem because of that global value, you typically have > forgotten you put it there. > > Have you thought about using a Makefile? Or a make.bash/test.bash script? I think my ideal solution would be more specific to vendoring; for > example a sort of pragma in vendor/modules.txt that tells the > toolchain to act as if there is no vendoring after all. But I don't > know the topic well enough to understand the implications of that. > > One possible solution that is possible now is to set the go version in the go.mod file to 1.13, so that the vendor directory is ignored: https://github.com/golang/go/blob/2e59cc5fb4/src/cmd/go/internal/modload/init.go#L699 However it will prevent the use of recent features, like the embed package. Manlio -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/574efa7d-8d01-43ec-a46f-82c1b14c1ad3n%40googlegroups.com.
