Hi Thank you all for your suggestions. Since there has been no response from Laszlo, I will implement the recommendations from your suggestions. I will inform the upstream about the conflict caused by the generic name "proto" and suggest a rename. Once I have worked on a patch, I will submit it to the bug report and give Laszlo two weeks to respond before proceeding with the NMU.
Best, Yogeswaran. On Tue, Jun 11, 2024 at 10:58:26PM +0900, Simon Richter wrote:
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
signature.asc
Description: PGP signature
