Add parameters to py_import_func

[casassg]

Opening this mostly for discussion. Right now there's no easy way to change import paths from protoc commandline. parameters would be a way to do so (you could have a parameter which prefixes all generated packages by a common prefix, which is useful if you want to avoid collision w other libraries). right now, I'm doing this w some sed+grep magic as it's not easy to access these protoc parameters from py_import_func.

This is a breaking change, I can try to make it non-breaking but may require some python wizardy stuff (parse signature from provided py_import_func and provide parameters or not depending on that.

[fischor]

I dont understand the problem that you are trying to solve.

you could have a parameter which prefixes all generated packages by a common prefix, which is useful if you want to avoid collision w other libraries

Why must this prefix be parametrized?

What I do usally in the import function is configure the postfix, like _dataclasses.py, to correctly resolve to the python files that are generated by the plugin. So this is a static value per plugin.

But yes, we could pass the parameters to the py_import_func. For the implementation I would prefer the backwards compatible way to not break existing plugins.

[casassg]

the issue is that sometimes you may want to prefix the generated files into a submodule of your own. This is needed specially on cases where google libraries are installed with generated google libraries. Their modules could conflict w the generated modules (see: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/ ).

Another dangerous case is when pip tries to install 2 libraries w the same generated files (aka 2 files generated by the same protoc-extension and added into 2 separate libraries for example google.protobuf.struct_dataclasses pip will overwrite it w whatever is the last version). This can create conflicts if for example each library has used a different version of the extension to generate the file (its probable that each does it in different versions). So to avoid it, we can generate it under our own module (let's say I'm creating a library called hero, i could place all generated files under hero._gen_proto to ensure it would not be overwritten by other libraries and to ensure the files i'm using are the same on development and installation.