go get: dial tcp: lookup non.existent.com: no such host

[pwaller]

Following the instruction in the README to do go get -u github.com/dvyukov/go-fuzz/..., I get errors:

~/.local/src/github.com/dvyukov/go-fuzz$ go get -u github.com/dvyukov/go-fuzz/...
go: finding github.com/stephens2424/writerset v1.0.2
go: finding github.com/robertkrimen/godocdown v0.0.0-20130622164427-0bfa04905481
go: finding github.com/Julusian/godocdown v0.0.0-20170816220326-6d19f8ff2df8
go: finding github.com/stretchr/objx v0.2.0
go: finding github.com/robertkrimen/godocdown latest
go: finding github.com/Julusian/godocdown latest
go: downloading github.com/stephens2424/writerset v1.0.2
go: extracting github.com/stephens2424/writerset v1.0.2
go build non.existent.com/foo: no Go files in 
~/.local/src/github.com/dvyukov/go-fuzz$ go install -v ./...
Fetching https://non.existent.com/foo?go-get=1
https fetch failed: Get https://non.existent.com/foo?go-get=1: dial tcp: lookup non.existent.com: no such host
Fetching https://non.existent.com?go-get=1
https fetch failed: Get https://non.existent.com?go-get=1: dial tcp: lookup non.existent.com: no such host

The underlying reason is that there is some test code which it tries to build which imports a non-existent package.

This could be avoided by moving all of the commands to a /cmd/... directory and updating the instruction to go get -u github.com/dvyukov/go-fuzz/cmd/..., or alternatively doing something to the test package to prevent it from being imported in this way, perhaps?

[pwaller]

Sorry, I had a go.mod lingering around that I didn't realise wasn't in your repository.

So I was able to work around this by setting GOPATH and deleting the go.mod.

I guess this will be a problem once go-fuzz becomes a go module?

[josharian]

I'm not sure I understood what went wrong here. But yes, go-fuzz needs module support on two fronts: Becoming a module itself and fuzzing modules. The latter is #195. The former is blocked on understanding how to find go-fuzz-dep and other support packages; see my comments at golang/go#30515 (comment).

[pwaller]

This might shed light:

go-fuzz/test/test.go

Lines 10 to 11 in 9cfa592

	// Test vendoring support.
	vendored_foo "non.existent.com/foo"

It's a test for vendoring support, and I guess go modules are just ignoring the vendor'd packages.

[josharian]

Ah! Thanks, yes, that clears it up. For now, I'll update the readme to recommend 'go get' with just the two relevant packages. Much of this will probably need to be re-thought when module time is upon us, but I can at least fix the docs in the meantime.

I'm not sure what to do about the impending module crisis that will hit when Go 1.13 is released...