Support running plugin without installing betterproto

[boukeversteegh]

Let's us run protoc with betterproto/plugin.py , without installing betterproto

git clone git@github.com:danielgtaylor/python-betterproto.git betterproto-script-demo
cd betterproto-script-demo
pipenv install --ignore-pipfile
mkdir example
pipenv run protoc \
  --plugin=protoc-gen-custom=betterproto/plugin.py \
  --custom_out=example \
  betterproto/tests/inputs/bool/bool.proto

Before:

Traceback (most recent call last):
  File "betterproto/plugin.py", line 10, in <module>
    from betterproto.casing import safe_snake_case
ModuleNotFoundError: No module named 'betterproto'
--custom_out: protoc-gen-custom: Plugin failed with status code 1.

Here you needed to install betterproto so it can reference itself when run from as plugin (script)

After

Writing __init__.py
Writing betterproto/tests/inputs/__init__.py
Writing betterproto/tests/inputs/bool/__init__.py
Writing betterproto/tests/inputs/bool/bool.py

[nat-n]

I have mixed feelings about sys.path hackery.

Also not sure about the value of supporting such a use-case.

That said, it's a nominal improvement with quite limited footprint, assuming no-one has reason to import this module into another script.

I'd feel better about it if the script were split up into multiple module with a minimal entry-point (maybe as part of #49 after the current round of PRs are merged), or if it attempted to work without path jiggery, and then falls back, such as with a try/except around import betterproto.

[boukeversteegh]

I have mixed feelings about sys.path hackery.
Also not sure about the value of supporting such a use-case.

Yeah, I don't like it either. The use case is that as a developer, I want to clone the repo, install the dependencies and be able to run the plugin as i'm writing code, without "reinstalling" betterproto when I change the plugin implementation. Its a bit strange for a module to have a dependency on itself that needs to be installed as a package.

That said, it's a nominal improvement with quite limited footprint, assuming no-one has reason to import this module into another script.

I'd feel better about it if the script were split up into multiple module with a minimal entry-point (maybe as part of #49 after the current round of PRs are merged), or if it attempted to work without path jiggery, and then falls back, such as with a try/except around import betterproto.

This is actually what I was also thinking of. betterproto/__init__.py and betterproto/plugin.py should have basically nothing in it, except imports, and possible this path jiggling to make it work with protoc.

Alternatively, we could provide an executable (e.g. betterproto/plugin.sh, or even bin/betterproto that simply runs python -m betterproto.plugin. I've tested this already and that works too.

[nat-n]

Regarding the use-case, maybe poetry eases this... I've not tried but I expect the following to work:

git install ... && cd ...
poetry install  # build virtualenv etc
poetry run protoc ...

Actually the same workflow should work with pipenv I think.

If it's still a pain point after the other pending PRs then it might still be worthwhile.

I kinda like the idea of providing/installing a betterproto executable that wraps protoc for convenience.

Some makefile alternatives could also make this smoother for development:

poe protoc [extra_args...] [input_files...]

[boukeversteegh]

No longer needed since when running poetry shell, its possible to just run the plugin with --python_betterproto_out as poetry generates the script protoc-gen-python_betterproto