The reason you're running into this is that this repository is not yet a go module, as the versioning and package name are not compatible with Go's conventions; adding a go.mod would break the repository currently until we rename the project.

we use a vendor.mod file to specify the dependencies (which is a custom name for go.mod), which is used through the hack/vendor.sh script (which creates a temporary go.mod file to use during vendoring, but is not used after that); also see #44497

closing this because of that, but feel free to continue the conversation

@thaJeztah Previous releases build correctly with go build -mod=vendor but master and the latest beta release do not.

Please fix this so that we don't have to change our entire build tooling in Buildroot just for this package.

Previous releases didn't use the go mod tool for performing the vendor, so didn't put a modules.txt inside the vendor directory, which is probably what trips up what you saw; you should be able to build this with GO111MODULE=off if the source is in GOPATH

@thaJeztah That causes a couple more issues:

• We set modcacherw which causes a go tool error when GO111MODULE=off
• We rely on the module path matching to find the path to cmd/docker as github.com/docker/docker/cmd/docker

... overall this causes a bit of a nightmare on our end.

@thaJeztah Seems like setting GO111MODULE=off also disables the vendor/ path lookup...

cmd/dockerd/daemon_unix.go:22:2: cannot find package "golang.org/x/sys/unix" in any of:
        /lib/go/src/golang.org/x/sys/unix (from $GOROOT)
        /host/share/go-path/src/golang.org/x/sys/unix (from $GOPATH)

Why can't it be the way it was before, which worked fine & played nice with the go mod infrastructure?

Does it work if you remove the modules.txt before building?

@thaJeztah That works & is a reasonable workaround. Thanks.