On Fri, Jun 4, 2021 at 11:53 PM Amnon <amno...@gmail.com> wrote: > > How about renaming your vendor directory to something else?
That is not really an option because it is not "my" vendor directory. For example, there is a lot of Ruby code in this repository, which some people install with 'bundle install --deployment' which creates a '/vendor/ruby' directory. > On Friday, 4 June 2021 at 21:44:33 UTC+1 Brian Candler wrote: >> >> I don't suppose you could move all the go code down a level, say into a "go" >> subdirectory of the repo, including the go.mod file? That is more or less the situation we're in now and I want to move towards a top-level go.mod for the sake of automatic dependency scanner tools (license detection, vulnerability scanners). >> On Friday, 4 June 2021 at 17:44:37 UTC+1 manlio....@gmail.com wrote: >>> >>> On Friday, June 4, 2021 at 6:24:28 PM UTC+2 Jacob Vosmaer wrote: >>>> >>>> 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? We already have a Makefile for the Go code. That is fine for building the software, but not great for development because the Go code I'm talking about now has 34 packages and you don't always want to run 'go test' for all 34 of them. The moment you need fine grained control I think you need to use the go tool chain. If there was a local version of `go env`, as you suggested earlier, then we could bootstrap that from our Makefile. >>> >>> 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. Thanks, that would indeed work, but it's not tenable in the long run because someone will want to use new Go language features at some point. Too bad, it doesn't sound like there are any good options for me. -- 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/CADMWQoOSxJRjcF7Aq1%2BcUx5_GSTgWvKhE_7oDhbps3JXRgSQqw%40mail.gmail.com.
