Import bug - two packages with the same name suffix should not cause naming conflict

[ansAFinney]

I am keen to use better proto for a project that contains a simple heirarchy of protobuf files.
There is a top level proto file which contains the include statements:

package adapter.v1;

import "Src/Products/HFSS/Adapter/v1/API/aedt-method-data-v0.proto";
import "Src/Products/HFSS/Adapter/v1/API/aedt-properties-v0.proto";

The imported proto have package definitions of the form:

package aedt.method_data.v0;

and

package aedt.properties.v0;

In the python generated by better_proto for the top level proto I see:

from .aedt.method_data import v0
from .aedt.properties import v0

with an example reference:

@dataclass
class UpdateBigHouseRequest(betterproto.Message):
    # The big_house resource which replaces the resource on the server.
    big_house: v0.BigHouse = betterproto.message_field(1)
    # The update mask applies to the resource. For the `FieldMask` definition,
    # see https://developers.google.com/protocol-
    # buffers/docs/reference/google.protobuf#fieldmask The grpc gateway will add
    # entries for all fields in the request body JSON (i.e. the payload above) to
    # the update_mask. This means a REST client needs to filter-out fields not
    # present in the update_mask from the body JSON it sends.
    update_mask: protobuf.FieldMask = betterproto.message_field(2)

I hope you agree this is incorrect.

I think the solution is to revise the code in plugin.py lines 79 and 80 in the get_ref_type function
to something like:

        imports.add(f"import {'.'.join(parts[:-1])}")
        type_name = '.'.join(parts)

I have not tried this as I have had difficulty building from a clone of the repository.
(perhaps the following should be separate issue...)

I tried
python -m pipenv install --dev
at the root of the clone
and got:

Traceback (most recent call last):
  File "C:\Users\afinney\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\afinney\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\__main__.py", line 4, in <module>
    cli()
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 717, in main
    rv = self.invoke(ctx)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\click\decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\cli\command.py", line 235, in install
    retcode = do_install(
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\core.py", line 1734, in do_install
    ensure_project(
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\core.py", line 570, in ensure_project
    ensure_virtualenv(
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\core.py", line 494, in ensure_virtualenv
    python = ensure_python(three=three, python=python)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\core.py", line 397, in ensure_python
    path_to_python = find_a_system_python(python)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\core.py", line 360, in find_a_system_python
    python_entry = finder.find_python_version(line)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\pythonfinder\pythonfinder.py", line 108, in find_python_version
    match = self.windows_finder.find_python_version(
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\pythonfinder\pythonfinder.py", line 63, in windows_finder
    self._windows_finder = WindowsFinder()
  File "<attrs generated init 7fb3eb7472e6350f51fd6e21deda174661985e11>", line 13, in __init__
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\pythonfinder\models\windows.py", line 92, in get_versions
    py_version = PythonVersion.from_windows_launcher(version_object)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\pythonfinder\models\python.py", line 417, in from_windows_launcher
    creation_dict = cls.parse(launcher_entry.info.version)
  File "C:\Users\afinney\AppData\Roaming\Python\Python38\site-packages\pipenv\vendor\pythonfinder\_vendor\pep514tools\_registry.py", line 75, in __getattr__
    raise AttributeError(attr)
AttributeError: version

I then tried

python setup.py develop

which appeared to successfully create the protoc plugin
but running the protoc with the generated plugin did not create any generated code

[boukeversteegh]

I spent some time today figuring out how to run this thing. Here's what I did (on windows).

• Run pyenv with explicit python path argument, and disabling lock file

  pipenv install  --dev --pre --skip-lock --python C:\bin\python38

• Create a file plugin.bat next to betterproto/plugin.py

  @SET plugin_dir=%~dp0
  @python %plugin_dir%/plugin.py %*

• Run protoc with custom plugin path (straight from source)

  protoc --plugin=protoc-gen-custom=C:\projects\python-betterproto\betterproto\plugin.bat --custom_out=. -IC:\projects\proto_test_files C:\projects\proto_test_files\*.proto

I ran these commands in a bash-terminal, so on my system I used /c/projects etc instead of c:\projects.

Let me know how it goes.

[boukeversteegh]

I don't mind to have a look at this issue, but I'm not sure I understand exactly what the problem is, and the proposed solution.

Is it about a naming conflict (both packages imported as v0)? If so, how does your suggestion work?

[boukeversteegh]

I'm working on fixing several issues related to importing. I see that above was indeed a naming conflict. I have a work in progress branch available here:

https://github.com/boukeversteegh/python-betterproto/tree/fix/package-imports

Would you be able to try it out?

If not, would you mind to send me your proto files? Then I will test it with them and we can see if it solves your issue.