Nice. I didn't know about grcp-tools. If we start using betterproto models in the compiler (which we really should) then maybe we don't need to depend on protobuf at all!

Unless the plugin actually uses grpc-tools I don't think it should be listed as a dependency. The user can install it if they want but shouldn't be forced to unnecessarily.

If we start using betterproto models in the compiler (which we really should) then maybe we don't need to depend on protobuf at all!

Yes indeed! With this PR we only depend on it for testing, so I think it only needs to be in dev-dependencies.

Yeah, I wasn't sure about that. Will drop the dependency from the compiler extra. Should the extra be called "plugin" instead of compiler? :)

will it still work with protoc as a plugin w/o the grpcio dep with this change?
those of us w/ multilanguage build pipelines are very negatively affected by dependancy to grpcio-tools

@aselus-hub no changes at all for users of protoc and this change does not impact functionality. This is done so that we can generate test files without having to install protobuf compiler and library out of band from the package's toolchain.

will it still work with protoc as a plugin w/o the grpcio dep with this change?
those of us w/ multilanguage build pipelines are very negatively affected by dependancy to grpcio-tools

If i understand correctly, the dependency is only there for development. So if your pipeline is just installing betterproto (including betterproto[compile]), and not with dev depenendies included, grpcio-tools will not be installed.

plugin.py does not reference grpcio-tools, so when you are running protoc --..... with the plugin, you'll have nothing to do with grpcio.-tools.

Yeah, I wasn't sure about that. Will drop the dependency from the compiler extra. Should the extra be called "plugin" instead of compiler? :)

Perhaps that makes a bit more sense yes. From the beginning I was confused what the [compiler] package was for. It took me some time to realize this library is needed for both generating and for referencing the python files, and that some people might want to reduce their runtime dependencies by excluding the plugin part.

From that respect, betterproto[protoc-plugin] would be even more clear. At least I would understand that immediately.

This also exposes a problem I hadn't realized before. The plugin is actually installed, even without the [compile] extras. This is because the script that protoc needs is defined in the project.toml (protoc-gen-python_betterproto), but not as part of the extras. If you then run the plugin, you'll get missing modules if you're lucky, or a exit code 1, if you're unlucky, with no failure message from protoc.

I'm not sure if its possible to move the script section into the extras, besides creating two different builds/packages.

From that respect, betterproto[protoc-plugin] would be even more clear. At least I would understand that immediately.

Maybe another PR? 2.0 might be a good version to make that change in.

I'm not sure if its possible to move the script section into the extras, besides creating two different builds/packages.

At the moment no. Although, this is part of an improvement coming in a future poetry version.

We can mitigate this issue by printing out some useful error message like "please install compiler extras using pip install betterproto[compiler]" when an import error occurs and calling exit. I can create another PR for this.

From that respect, betterproto[protoc-plugin] would be even more clear. At least I would understand that immediately.

Maybe another PR? 2.0 might be a good version to make that change in.

Sure!

We can mitigate this issue by printing out some useful error message like "please install compiler extras using pip install betterproto[compiler]" when an import error occurs and calling exit. I can create another PR for this.

Actually we have that, oops. But I remember the message doesn't show nicely if you run protoc with the plugin. Something to retest, now i'm not sure.

@aselus-hub do above answers take away your concerns? If yes, we can merge.

yup no concerns from me thank you for the check @boukeversteegh