Another interesting thing is that even if I add "_" to GOPRIVATE (and hence GONOSUMDB), running "go test" reports the "missing go.sum entry" as above which seems incorrect?

looks like it still works, are you sure you don't have a typo somewhere?

21:45:20 ~/tmp/46496 0:00:00
» go version
go version devel go1.17-e4615ad Wed May 26 13:25:43 2021 +0000 linux/amd64

21:45:30 ~/tmp/46496 0:00:00
» mkdir xxx && cd xxx && go mod init _/xxx
go: creating new go.mod: module _/xxx

21:46:17 ~/tmp/46496/xxx 0:00:00
» cat << EOF > xxx.go
package xxx
var X = 1
EOF

21:46:35 ~/tmp/46496/xxx 0:00:00
» cd ..

21:46:38 ~/tmp/46496 0:00:00
» mkdir yyy && cd yyy && go mod init _/yyy
go: creating new go.mod: module _/yyy

21:46:53 ~/tmp/46496/yyy 0:00:00
» cat << EOF > yyy.go
package main

import "_/xxx"

func main() {
        println(xxx.X)
}
EOF

21:47:33 ~/tmp/46496/yyy 0:00:00
» go mod edit -replace _/xxx=../xxx

21:47:44 ~/tmp/46496/yyy 0:00:00
» go get
go get: added _/xxx v0.0.0-00010101000000-000000000000

21:47:49 ~/tmp/46496/yyy 0:00:00
» go run .
1

Also this..

$ go mod tidy
go: _/xxx/log@v0.0.0-pre: unrecognized import path "_/xxx/log": import path does not begin with hostname

in go.mod I'm using:

go 1.16

replace _/xxx => ../xxx

require _/xxx/log v0.0.0-pre

@seankhliao It seemed to break when I tried a "go test": can you check that works for you ok please?

(Also, in this case I'm using "_/xxx" imported into a module from "example.com/yyy", not sure if this changes anything).

Sorry, my bad!

I had an incorrect require directive, ie I had pointed to the package /xxx/log, not the module (/xxx)!

I guess I misunderstood the error message (this seems to be a common theme with me and modules lately!) [Not sure if anything can be done to improve error messages to better point to root causes?]

Sorry for the trouble, closing this as "not a problem". Thanks.

I guess I misunderstood the error message

We can always improve error messages!

I think it makes sense to give the missing dot in first path element error if we're trying to resolve a new module dependency (such as in go get or go mod tidy), but it probably doesn't make sense if the malformed path is already a module dependency (as is the case here).

Probably this error message should explicitly mention something about the fact that the path is invalid and has no replace directive.

(CC @matloob @jayconrod)

Sorry for this late input, but this just occurred to me: Considering the problem from first principles and using a "test-first" style:

Given the code I had, what is my "expected error message"?

Answer:

"_/xxx/log" is not a module (please check go.mod require directives)

or something along those lines. The main point here is that the current message isn't pointing clearly enough to the root cause of this problem (at least for my naive eyes), and in effect "miss directed" me!

Now, I realize that achieving this end goal may well be a difficult task, but it's this kind of user-friendliness that can save many hours of developer time, so sometimes it's worth seeing if it's possible (I believe that one of Clang's great improvements over gcc was it's error reporting, so I'm thinking along similar lines to that). In this case being told "you're referring to something that isn't even a module in go.mod" would be ideal and help productivity.

Something to consider?