Import generated proto code from google.golang.org/genproto

[jba]

Soon all generated proto files for Go will live at google.golang.org/genproto/... (which will map to the repo github.com/google/go-genproto). Generated code should use those import paths.

The import paths will not map directly to the proto package. The exactly relationship still hasn't been decided, but it's likely that code generated from googleapis/googleapis will have paths "googleapis/foo/bar", while well-known types and a few protos in google/apis will have different paths. Probably the best implementation will be a map of exceptions, and a fallback that does s/google/googleapis/.

Details forthcoming.

@okdave

[saicheems]

Any leeway on matching the proto package structure? It may be a late ask, but one issue with code generation is that proto paths are generated from either the proto package, or a specified go_package.

If the generated proto repo doesn't match the package hierarchy, we can still get around it for most protos by adding go_package vars to all the protos in googleapis/googleapis. Since the package protobuf isn't in our googleapis repo, I've always used a "hack" locally to ensure codegen got the right package path for imports.

If this has already been decided...
Michael: one possible solution, and maybe the least painful is to manually override the repo location of packages in the Go import handler.
It's not ideal... but theoretically you'd only have to force rename google.protobuf to github.com/google/go-genproto/foo/protobuf. For all the other protos, a possible solution is to add go_package to everything under googleapis/googleapis.

[jba]

I think it's reasonable to add go_package wherever necessary. That would be done inside google3 for the files under /google/api. The well-known types already have a go_package.

[jba]

The repo is ready. Browse at https://github.com/google/go-genproto, import from google.golang.org/genproto. Note that the ptypes package (containing well-known types like timestamp) was not moved.

As an initial task, you can regenerate the logging client. It uses monitored_resource, which is not in the same place as its proto package would suggest. Let me and @okdave know if you run into issues.

[pongad]

Fixed by #327.