import_prefix shouldn't be used for non-proto packages

[zellyn]

We're trying to figure out how to generate our protos into a subdirectory, so they don't collide with existing code. We also have a mix of our protos, and a few externally-created protos (eg. proto descriptors, etc.)

It almost works to use import_prefix to add a "protos" subdirectory on the front of every proto import.

However, the import_prefix is also applied to three normal Go package imports: proto runtime, context package, grpc package.

It's difficult to imagine a scenario where one would want to try to import golang.org/x/net/context from inside a generated-protobuf directory, especially given the vendor/ folder semantics.

[zellyn]

/cc @jhump

[warebot]

+1 To this proposal.
Ended up with "sed" hacks to make this work.

[zombiezen]

import_prefix predates the vendor/ subdirectory. I agree it's confusing, but changing its functionality now could cause breakage to people's build processes. One possibility is that we could introduce a new flag that has the functionality you describe, but I think that such a design proposal would need to also consider how this would interact with the go_package option.

[jmasonISP]

+1 To this proposal as well. In its current state, import_prefix is unusable for us because it is added to the import of proto runtime and other packages. My short term solution will be to update the proto-gen-go plugin to omit using the import_prefix for importing the proto runtime et al.

I am also OK with adding a new parameter the performs the desired "proper" import prefix.

Edit: I've fallen back to using the go_package option instead of using a modified version of proto-gen-go

[neild]

I really don't understand why you'd ever want the current behavior of import_prefix. However, I also don't understand why you'd want to use import_prefix at all; what does it give that you can't get in a better fashion by including a go_package option in each source file to specify the correct import path?

I'm inclined to say that we should deprecate or remove import_prefix rather than tweaking it.

[dsnet]

The import_prefix flag is considered deprecated. The recommended approach is to specify a go_package option.