Manually adding replace directives for all dependent packages (probably 30-40 now, who knows how many after a few years) sounds like a fairly horrible maintenance cost, but maybe I'm missing a way to use them easily? Is there a page somewhere with a good writeup of these directives?
Re: Using the vendor dir approach, I did re-read the `go help modules` text, the last section particularly:
-----
Modules and vendoring
When using modules, the go command completely ignores vendor directories.
By default, the go command satisfies dependencies by downloading modules
from their sources and using those downloaded copies (after verification,
as described in the previous section). To allow interoperation with older
versions of Go, or to ensure that all files used for a build are stored
together in a single file tree, 'go mod vendor' creates a directory named
vendor in the root directory of the main module and stores there all the
packages from dependency modules that are needed to support builds and
tests of packages in the main module.
To build using the main module's top-level vendor directory to satisfy
dependencies (disabling use of the usual network sources and local
caches), use 'go build -mod=vendor'. Note that only the main module's
top-level vendor directory is used; vendor directories in other locations
are still ignored.
-----
So I guess we can use `go mod vendor` and then `go build -mod=vendor` but is this a long term solution? It seems like the community desire is to move away from vendor dirs. If vendor dir support is eventually completely removed, will replace-directives be the only way to have network-less builds? I guess if this is the case we should probably just use vendoring until it's removed, then pay the price to switch.