It seems like this change would make it impossible for one-off generator code to use internal packages. Supposing that this is fixed as you suggest but also that we did want to add a compress/flate/internal/huffman package, how could we implement compress/flate/gen.go instead?

I'm sorry, but the fact that people use the bug does not make it less of a bug. Internal means internal.

Russ, on the one hand you want go run to behave more like other tools, to the point that it should be able to run an entire package. But on the other hand, go run should ignore the package a file is part of? go build x.go doesn't behave that way.

Personally, I thought that the "a separate workspace" aspect was an implementation detail, not the public interface, and that go run was supposed to be a shorthand for go build + ./a.out, not for cp foo.go /tmp/...

@rsc I agree that "go run" and "go build" need to be made internal-aware. It's certainly a bug that "go run $GOPATH/src/foo/x.go" currently works even if foo/x.go imports internal packages from the standard library like net/http/internal.

It's just not obvious to me that "go run $GOROOT/src/net/http/x.go" should fail if net/http/x.go imports net/http/internal, because it would complicate some seemingly reasonable use cases for mixing "internal" and "go generate".

A simple concrete proposal would be that if the files passed to "go build" or "go run" are all within the same directory, then they should be allowed to import internal packages just as normal package code within that same directory could. For example, $GOROOT/src/net/http/x.go could import net/http/internal, but not $GOROOT/src/cmd/internal/gc.

The proposal could be extended to files spread across multiple directories too, but I'm not sure there's a need.

Will let this stand unless more evidence accumulates that this is a mistake.