cmd/go: allow local replacements without a corresponding explicit requirement?

[bcmills]

In CL 153157, I added code so that a module path that has a replace directive resolves to a pseudo-version of the form vX.0.0-00010101000000-000000000000 rather than checking for upstream dependencies.

That unblocks builds, but means that the module graph may indicate a commit that doesn't actually exist. There are use-cases for such a configuration, such as testing against unpublished commits of upstream modules (see #26241 (comment) and #32776), but since the commit does not actually exist, the requirement graph of the resulting module cannot be used without a corresponding replace directive in every downstream consumer.

Since this pseudo-version has an unambiguous and very unique commit hash (all zeroes!), I propose that we special-case it (if unreplaced) and treat it as equivalent to an empty commit.

CC @jayconrod @thepudds @rogpeppe

[bcmills]

Thinking about this some more, I think using the zero-version was a mistake.

Instead, we shouldn't be writing the require directive out at all: we don't know any valid version to require, and if a downstream consumer requires our module they're better off resolving latest instead.

That seems to support the second case considered in #26344 (comment): this sort of wildcard replace directive effectively means “select the latest version (none), and then select this replacement as if it were a slightly-higher version.”

[gopherbot]

Change https://golang.org/cl/220080 mentions this issue: design/36460: add design for lazy module loading

[bcmills]

That seems to support the second case considered in #26344 (comment): this sort of wildcard replace directive effectively means “select the latest version (none), and then select this replacement as if it were a slightly-higher version.”

Thinking about this further: it is often useful (for testing) to be able to slot in dormant replace directives and then run various go get commands to see what happens. As of Go 1.16 go get correctly mixes in the replacement versions, so that actually provides a fairly high-fidelity simulation of what would happen after the replaced versions are published.

So I think this sort of “select-and-replace” form should actually have a different syntax; perhaps one derived from (or identical to) the “replacement alias” form (#26904).