cmd/go: poor error message when running 'go mod download' on a path that can only be used if replaced

[marystern]

What version of Go are you using (go version)?

$ go version
go version go1.16.4 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

As per a previous discussion (ref #37554 ), I'm using "_" as a domain for local packages. This used to work pre 1.16. It now seems to be broken as of 1.16?

go: _/xxx/log@v0.0.0: missing go.sum entry; to add it:
	go mod download _/xxx/log

$ go mod download _/xxx/log
go: _/xxx/log@v0.0.0: malformed module path "_/xxx/log": missing dot in first path element

.. I believe that this used to work fine?... :(

Is this an intentional break? If so, can you please re-visit #37554 and suggest a better way of working? (For what it's worth, it's becoming harder and harder to "just code" in Go due to these recent "improvements" in 1.16, or I'm simply making a silly mistake?).

[marystern]

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?

[seankhliao]

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

[marystern]

Also this..

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

[marystern]

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?

[marystern]

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

[seankhliao]

22:01:02 ~/tmp/46496/yyy 0:00:00
» cat << EOF > yyy_test.go
package main

import "testing"
import "_/xxx"

func TestImport(t *testing.T) {
        if xxx.X != 1 {
                t.Errorf("oops")
        }
}
EOF

22:02:49 ~/tmp/46496/yyy 0:00:00
» go test
PASS
ok  	_/yyy	0.001s

[marystern]

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.

[bcmills]

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)