consider making go-fuzz a proper module itself

[thepudds]

go-fuzz has reasonable support for targeting modules (#274), but is not itself a module.

Currently, the easiest way to build go-fuzz locally with a recent Go toolchain might be to clone go-fuzz to $GOPATH/src/github.com/dvyukov/go-fuzz and then disable modules via GO111MODULE=off env var. From the go-fuzz repo root, you can then do go install ./go-fuzz ./go-fuzz-build or similar to get go-fuzz and go-fuzz-build binaries that then can be used to fuzz a module-based target with module mode enabled via GO111MODULE=on . (That said, multiple ways to do this, so "easiest" might be in the eye of the beholder).

Note this is mostly a concern if you want to hack on go-fuzz, and not as much of a concern if you are just using go-fuzz, because you can just install it without a local repo and without worrying about module mode, such as doing the following from anywhere (assuming a semi-recent Go version):

$ go install github.com/dvyukov/go-fuzz/go-fuzz@latest github.com/dvyukov/go-fuzz/go-fuzz-build@latest

I have the start of converting go-fuzz to a module, but right now, there are some annoying glitches with the dev Go 1.18 and Go 1.17 not agreeing with what needs to be in go.sum, which can then cause failures based on which version of Go is in use. (Or at least I think that was a problem recently -- I haven't checked just now to see if it is still the case, including because I'm a few yaks deep and that is a yak I am saving for later).

So I think it could be mildly helpful to make go-fuzz a module itself, but if so, I would suggest letting Go 1.18 settle down a bit more first.

[josharian]

I'd suggest also filing an issue upstream; 1.18 is probably mostly settled at this point, and if they don't know about an issue, it definitely won't get addressed. :)

[thepudds]

I think it might be golang/go#49598, but I need to confirm.