It looks like protobuf codegen for python leads to a common problem with incorrect imports when you use

protobuf_sources(grpc=True)

. I think it's related to this unresolved issue. For example, the file

//protobuf/third_party/a_pkg/a.proto

will create a file

dist/codegen/protobuf/third_party/a_pkg/a_pb2_grpc.py

, which attempts to do an import like:

from a_pkg import ...

. This import fails, since it would need to be

from protobuf.third_party.a_pkg import ...

. In the thread I linked, it looks like there's a fix by passing different arguments to protoc, is there a way to do this with

protobuf_sources

?

Sorry for the trouble! Do you have a specific protoc CLI invocation you’d like to reproduce in pants? (Pants mostly just wraps external tools, so working backwards from “how I want to run the tool” to “how to make run it like that” is often productive$

Actually upon looking further, it seems like there might not be a flag that does it, since I'd misunderstood some of the advice in the thread. This tool patches the codegen'd python after the fact, so maybe what we need is to run a post

export-codegen

hook somehow.

ah I see. You might be able to chain something up with

adhoc_tool

+

experimental_wrap_as_python_sources

to run that tool. Another option would be to 'just' suffer the protoc layout and import them a the top level rather than

protobuf.third_party.a_pkg

. I understand that might be very undesirable, though.

Currently we're working around it by storing them at the top level yeah. I'll take a look at the

adhoc_tool

approach, thanks for the pointer.