Jay Conrod

Thanks! Not sure how I missed that. Added a test case there.

Sorry I haven't gotten back to this yet! I'll take some time this weekend and try to finish it. I ran into some trouble with the testing framework and was...

In #3856, I've moved `gopackagesdriver_test` into `//go/tools/gopackagesdriver`. Since it embeds the library instead of calling via `bazel run`, the test is considerably easier to write, debug, and faster to iterate...

This overlaps a bit with #40357, but I assume if a module author explicitly deprecates a major version with a comment in `go.mod`, then the `go` command wouldn't also show...

This issue shouldn't be relevant anymore now that `GOPATH` is mostly dead. It was referring specifically to comments like this: ``` package otlpconfig // import "go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig" ``` Before Go modules,...

I'd recommend against setting `GO111MODULE=on` globally. That was useful for working on modules checked out into `GOPATH` in Go 1.12 or earlier, but since `GO111MODULE=auto` was changed in 1.13, I...

There's been some renewed attention on this issue, since `GO111MODULE` defaults to `on` in 1.16. It's not clear to me what folks want to change though. In module-aware mode, if...

@thepudds Yes, `go build` would be equivalent to `go build .`, which should work.

Discussed this with @bcmills, @matloob, and @_rsc. I think we're all agreed this is a good idea. One clarification, `go run .` should still apply build constraints, same as if...

I like this proposal. I've had something similar in my drafts folder for a while. @bcmills touched on the main difference. `go.mod` would have a `tool` directive that would name...