By 'src', do you mean $GOPATH/src'?

Yes, sorry. I added that.

Well, then it works as intended. The import path of a package may not be empty.

I'm not sure I understand:

• The "main" package in "$GOPATH/src" is not imported anywhere so there is no "import path".
• You seem to to imply that the "$GOPATH/src" directory must be empty. Go accepts and works nicely with code in that directory. I also didn't find any documentation that states that there must be no code. Can you point me to such a requirement?
• I would argue that displaying "Command ." is not intended as it's rather confusing. On a side note, for a package "abc/xyz/main", the header will say "Command main." (It's not the import path that's displayed.)

Maybe I'm missing something?

The "main" package in "$GOPATH/src" is not imported anywhere so there is no "import path".

All packages inside GOPATH have a package path, even if they are never imported.

Also, note that the Command <x> part doesn't use the package name, but the last element of the package path. If you create a main package in $GOPATH/src/foo, it will show Command foo. That's also the name that people will go get and use as a binary, which is why it's useful. Otherwise all main package doc pages would seem the same.

I also didn't find any documentation that states that there must be no code. Can you point me to such a requirement?

I don't recall such an explicit piece of the docs, but it's very rare for people to put code there. It's not importable, it can't be used with go get, and it has none (or a confusing?) package path. I'm not sure why it would ever be useful.

Thanks for the explanation. I understand that it's not recommended to put code in $GOPATH/src for the reasons you mentioned. The code I put there is not meant to be imported anywhere. It's simply the main() function of my application (plus some general application documentation).

Maybe I'm just confused that Go as well as Godoc work well with that scenario (except for the point raised in this issue). In many other places, Go throws compile errors for things that are not recommended. Maybe "Package path must not be empty" would be a reasonable message. But it may break a lot of projects that do what I'm doing here. And these projects will always see a weird page title "Command ."

It's not a huge issue so feel free to close it if you feel this case should not be handled. Personally, I think a small addition here could do the trick:

if tabtitle == "" {
    tabtitle = "main"
}

Instead of twisting the Go tool to support things it does not support for good reasons just mkdir $GOPATH/src/tmp and put any throwaway code there.

Personally, I think a small addition here could do the trick:

I don't think that would be a good change to do - the package name could be something other than main. A non-main package in that directory makes even less sense as it's completely useless, but hard-coding main like this could lead to even more confusion.

I think falling back to the package name when the package path is . could be easily as confusing, to be honest. It would break the consistency of what Command <x> means.

I'm not going to close this issue myself, because I'm not certain as to what degree the "root" package path is supported and supposed to work. Hopefully someone can come with a link that clarifies things one way or another. Otherwise, I'm not convinced that there's anything to fix in godoc here.

Actually, the package name is main, see here:

if info.IsMain {
	// assume that the directory name is the command name
	_, tabtitle = pathpkg.Split(relpath)
	title = "Command "
} else {
	title = "Package "
}

Further up, you will find:

info.IsMain = pkgname == "main"

Ah, my bad for misreading the code. The second part of my reply still stands, though.

This is kind of an edge case with no clear solution. While the Go docs does not explicitly forbid code inside the $GOPATH/src directory, it does mention to make a folder inside the workspace.

• https://golang.org/doc/code.html#Command
• https://golang.org/doc/install#testing

I would go further to say that the word "Command" is itself misleading for the package root at $GOPATH/src. Because "command" would mean that it is importing and running some other package. However, you can have as many main packages inside $GOPATH/src as you like, each doing its own separate thing. So to me, both . and main are equally confusing.

I would prefer to rename the title to "Root" or something similar. But keeping in mind that the docs suggest to create a folder, it might just be better to leave it as is and close the issue.

I like the idea of displaying "Root". Eventually, someone who hasn't seen the recommendation will wonder about it again. I don't see the harm in making it work for that edge case.

I have no opinions either way. Somebody else will have to take a call. Needs a NeedsDecision label.