Hmm this doesn't even appear to be specific to directory replace directives.

This is almost certainly a consequence of CL 251881 / #40728, and (except for the details of the error message) it's mostly working as designed.

That said, we should at least give a better error message when the arguments include one or more packages outside the main module (for which go mod tidy won't necessarily do any good). For packages outside the main module, go get would suffice as an alternative, but for individual source files there isn't really a good alternative to -mod=mod at the moment.

CC @matloob

(except for the details of the error message)

As discussed offline, the main problem here is with my bad repro 😄

The repro above does not include a // +build tools-esque file that _ requires blah.com, despite the fact that I thought it did in my local testing. Adding such a file ensures a require directive exists for blah.com with a v0.0.0-00010101000000-000000000000 version and all is good.

Thanks for taking the time to patiently discover the real cause (me)!

I'll take a look at this. There are some changes to go.mod that don't cause errors in -mod=readonly: things like adding a go directive to go.mod, formatting, or changing // indirect comments. Adding a null requirement for a replacement should probably be one of those (actually i thought it already was).

The null requirement can actually be significant, depending on what the replacement's go.mod file says about other dependencies. (For example, it can change the output of go list -m all for other modules — and will continue to do so even once we have lazy loading.)

@bcmills Just to confirm what you're saying, the two files below are not equivalent:

module mod.com

go 1.16

replace blah.com => ./blah

module mod.com

go 1.16

require blah.com v0.0.0-00010101000000-000000000000

replace blah.com => ./blah

If we don't load a package from blah.com, we won't add the null requirement or read the go.mod file from the replacement. That go.mod could require higher versions of other dependencies.

So it's correct that we report an error here, but the recommendation to run go mod tidy isn't helpful. go mod tidy doesn't fix this because packages in blah.com aren't in all.

@jayconrod @bcmills What are the next steps on fixing this, given that it is a release blocker?

I plan to work on this before the freeze. Should just involve fixing the error message.

Change https://golang.org/cl/258220 mentions this issue: cmd/go/internal/modload: allow 'go get' to use replaced versions

Change https://golang.org/cl/263146 mentions this issue: cmd/go: change error message for missing import with unused replacement

As of CL 258220, the error message is now:

$ go run blah.com
no required module provides package blah.com; try 'go get -d blah.com' to add it

If the replace directive specified some explicit version other than the latest one, that suggestion might fetch a version other than the intended one, but it's still much better than suggesting go mod tidy.

The go mod tidy suggestion from the original also suggests to me that there is an error in our inAll computation, possibly related to #37376.

Change https://golang.org/cl/263266 mentions this issue: cmd/go/internal/modload: fix sort condition in (*replacementRepo).Versions