Does this project support passing relative paths to protoc?

CZ-NIC / setuptools-grpc

Setuptools module for building protobuf and grpc service python modules.

GNU General Public License v3.0

5 stars 1 forks source link

Does this project support passing relative paths to protoc? #19

Open tekulvw opened 2 months ago

tekulvw commented 2 months ago

I'm generating proto code into myapp/codegen. At the moment, the generated files contain an absolute import import server_grpc_pb2 as server__grpc__pb2 instead of the correct relative import from myapp.codegen import server_grpc_pb2 as server__grpc__pb2.

stinovlas commented 2 months ago

It's not clear to me what are you trying to achieve. Can you please provide a minimal working example? Or perhaps link to the repository in question?

If you can construct a protoc command that works for you, please post that as well, it can help with debugging your problem.

smaginmi commented 1 month ago

I think what @tekulvw is describing is a decade old problem, discussed in this thread here: https://github.com/protocolbuffers/protobuf/issues/1491 I have run into this a couple of times myself. With setuptopls-grpc my solution was to build the pb2 files at the root of my project. This way the imports remain valid. Recently, with the need to use other installation methods, I modified the protoc command within the run step to use betterproto and get correct relative imports. My quick fix is: `protoc_args = ( args

["--python_betterproto_out", self.output_path, "--pyi_out", self.output_path] + [os.path.join(args)
[os.path.join(self.proto_path, proto_file) for proto_file in self.proto_files]. )` I would really appreciate it if you would include support for betterproto properly.

stinovlas commented 3 weeks ago

Thanks for pointing that out. I've been on a vacation, but I'll try to take a look at this in the upcoming week.

On the first glance, betterproto was last released in May 2020, which is 4 years ago. Is it still relevant to support this today?

Seeing your quick fix, I'm thinking about some way to specify arbitrary additional arguments to protoc command. That way, we wouldn't depend on betterproto per se, but it would allow its usage (and more).

ziima commented 3 weeks ago

betterproto is still under development and the last release was last year, not stable though.

stinovlas commented 2 weeks ago

I did not forget about this, it's just a bit more complicated than I thought. It seems that --python_betterproto_out actually replaces both --python_out and --python_grpc_out.

That means that my idea to just allow adding arbitrary command line arguments to protoc wouldn't work, because it would still generate _pb2 and _grpc files as well. While this may be desirable for a transition period to betterproto, it's probably not ideal in the long run.

I'll think a bit more about how to do this without introducing actual dependency on betterproto and without breaking everyone's workflow (although we are currently releasing beta versions of 1.0.0, so it wouldn't be unreasonable to make some sensible changes.