Proposal: move grpc plugin-plugin out of internal directory

[zellyn]

As suggested by the protobuf team in the Square/Google hangout, I'm creating a github issue for this.

• It's useful to write your own "plugin-plugins" for the go plugin.
• To do so, you need to write your own main() function, to link in your plugin.
• But you can't link the existing grpc plugin, because it's in an internal subdirectory. And you can't import the link_grpc.go file because it's in package main.
• There's no particular reason for the grpc plugin to be internal. Expecting people not to use open-source code—or making it more difficult to use—just adds friction.
• The go proto plugin doesn't create insertion points so you also can't easily write your own plugin that amends the generated go files (you can't do imports). And if you did, you'd probably reuse the existing plugin's generation mechanism, since it already exists and works fine.
• Using a forked version of the golang protobuf repo is increasingly painful: soon all the well-known types will point there too. I realize you can use a forked version for generation and the unforked version for compile, but, ugh. these are painful workarounds for a trivially fixed problem.

Note: in earlier (Nov 2015) email correspondence with @dsymonds, they expressed reluctance to consider the plugin's interface with plugin-plugins a supported API at all, and recommended we fork the protoc plugin and move the grpc package ourselves. But (a) you can just add a "caveat utilitor" note to the README, (b) we're fine with upstream changes breaking our stuff occasionally, and (c) forking and then tracking upstream entails all the same pain for us, plus having a fork.

[dsymonds]

Yeah, maybe it's okay with the appropriate caveat.