Hi, On 6/11/24 07:40, Yogeswaran Umasankar wrote:
It appears that nanopb's use of the module name "proto" does not align with the conventional identification of a Python module. Given this, it might be plausible to make this module private within the nanopb package. This adjustment could potentially resolve the conflict without affecting the dependent packages.
From a quick glance at the package, not completely. It seems the "proto" module is used by the generator only, which is called as a plugin from Google protoc, so I'm not sure it can be taken fully private.
I think it should be possible to rename this module though with little adverse effect.
The standard invocation certainly is convoluted[1], and given that CMake is usually not the first choice for cross compiling in embedded environments, I also expect that there will be a lot of users rolling their own -- but I don't see the name of the module used on that command line, only the name of the plugin.
The script tries to do a relative import and provides fallback code if that is not yet supported in the Python interpreter (which it is since 2007), so that might explain why the module is not up to current conventions.
Simon [1] https://github.com/nanopb/nanopb/blob/master/extra/FindNanopb.cmake
