mkdir mod-mod && cd mod-mod go mod init github.com/DavidGamba/mod-mod
Create a vendor directory that is a third party vendor dir, not Go code vendor.
mkdir vendor && touch vendor/hello
Create a main.go file with an external import, and try build it:
$ go build
main.go:9:2: cannot find package "." in:
$ go build -mod=mod
go: finding module for package github.com/DavidGamba/go-getoptions
go: found github.com/DavidGamba/go-getoptions in github.com/DavidGamba/go-getoptions v0.19.0
Common workarounds don't work.
$ cd vendor
$ go mod init github.com/DavidGamba/mod-mod/vendor
go: creating new go.mod: module github.com/DavidGamba/mod-mod/vendor
$ cd ..
$ go build
go: inconsistent vendoring in /home/david/test/mod-mod:
github.com/DavidGambafirstname.lastname@example.org: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
run 'go mod vendor' to sync, or use -mod=mod or -mod=readonly to ignore the vendor directory
What did you expect to see?
An option to tell go to always run in mod mode so it ignores the vendor directory used by other code in the monorepo. The option should be persisted in the go.mod file so there is no need to pass it to the command line every time and so other tools like gopls know about it.
What did you see instead?
vendor mode is assumed wrongly due to the presence of a vendor/ directory.
The text was updated successfully, but these errors were encountered:
The problem with GOFLAGS is that only applies for my environment and each executable in our project can be built with plain go build unless we do a release build were we insert the metadata with -ldflags in our build system.
It is a workaround every developer will be forced to apply which I suppose it is OK but it would be better if the go.mod file had that information.
@rsc Thanks for taking the time to respond, I appreciate having a clear path forward vs not knowing if this is a workflow that is planned for in the future.
As you commented in the liked issue:
There are already two ways to do this: a dummy go.mod or putting
your assets and Go code in sibling subdirectories of the repo root.
Both of those are feasible today, in contrast to adding an ignore directive.
In the case of the vendor dir, the dummy go.mod doesn't work but putting the go.mod in a sibling dir will certainly work.
Adding GOFLAGS="-mod=mod" also works.
I'll close this issue since this one is not reason alone to add ignore directives to the go.mod file.