[kiitos]

    Within the Google codebase and in projects using Bazel, directory layout for Go code is different than it is in open source Go projects: you can have multiple go_library targets in a single directory. A good reason to give each package its own directory is if you expect to open source your project in the future.

:o :o :o

are there really people saying that "giving each package its own directory" is in any way optional?? it is literally part of the language spec, what on earth would make anyone think otherwise??

edit: ok so bazel folks are just on a completely alternative timeline it seems

https://github.com/bazel-contrib/rules_go?tab=readme-ov-file...

    Bazel ignores go.mod files, and all package dependencies must be expressed through deps attributes in targets described with go_library and other rules.

so bazel doesn't support go, gotcha

[matttproud]

Maybe better put: Bazel (and its predecessor) do support Go, but they don't support the traditional directory structure-to-import path semantic that we've come to expect in the outside world. And even then, the terminal directory needn't match the package name, but accomplished Go developers seldom violate that convention these days — thankfully.

All of this makes it paramount for developers of Go tools to use a first-party package loading library like package packages (https://pkg.go.dev/golang.org/x/tools/go/packages), which can ameliorate over this problem through the specification of a GOPACKAGESDRIVER environment variable to support alternative build systems and import path layouts (the worst thing someone can do is attempt to reverse engineer how package loading works itself versus delegating it to a library like this).