Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marystern opened this issue Jun 1, 2021 · 9 comments

Comments

@marystern
Copy link

@marystern marystern commented Jun 1, 2021

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
Copy link
Author

@marystern marystern commented Jun 1, 2021

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
Copy link
Contributor

@seankhliao seankhliao commented Jun 1, 2021

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
Copy link
Author

@marystern marystern commented Jun 1, 2021

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
Copy link
Author

@marystern marystern commented Jun 1, 2021

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
Copy link
Author

@marystern marystern commented Jun 1, 2021

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

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented Jun 1, 2021

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
Copy link
Author

@marystern marystern commented Jun 1, 2021

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.

@marystern marystern closed this Jun 1, 2021
@bcmills
Copy link
Member

@bcmills bcmills commented Jun 1, 2021

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)

@bcmills bcmills reopened this Jun 1, 2021
@bcmills bcmills changed the title "_" changed to be no longer a valid domain in 1.16? ("missing dot in first path element") cmd/go: poor error message when running 'go mod download' on a path that can only be used if replaced Jun 1, 2021
@bcmills bcmills added this to the Backlog milestone Jun 1, 2021
@marystern
Copy link
Author

@marystern marystern commented Jun 5, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants