There is a file conflict between python3-proto-plus and nanopb. The
conflict arises due to both packages has a file at /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining python3-proto-plus, and I am seeking guidance.
The module name "proto" is an integral part of the python3-proto-plus package. Renaming the "proto" module in python3-proto-plus would significantly impact future dependent packages.
It appears that nanopb's use of the module name "proto" does not align
with the conventional identification of a Python module.
I have attempted to reach out to the nanopb maintainer to discuss this
issue, but I have not yet received a response. In case the maintainer is
MIA, should I proceed with renaming the "proto" module in nanopb to "nanopb-proto"?
There is a file conflict between python3-proto-plus and nanopb. The
conflict arises due to both packages has a file at /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining python3-proto-plus, and I am seeking guidance.
The module name "proto" is an integral part of the python3-proto-plus package. Renaming the "proto" module in python3-proto-plus would significantly impact future dependent packages.
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.
I have attempted to reach out to the nanopb maintainer to discuss this
issue, but I have not yet received a response. In case the maintainer is
MIA, should I proceed with renaming the "proto" module in nanopb to "nanopb-proto"? As one of the team members, I am willing to implement
this change if it is deemed the best solution.
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.
Thank you all for your suggestions. Since there has been no responseThanks for your patience. I'm here just running back and forth. Going
from Laszlo, I will implement the recommendations from your suggestions.
Thanks for your patience. I'm here just running back and forth. GoingAs promised, I reported it to upstream yesterday. Turns out it was my
to note nanopb upstream this afternoon.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 146:01:57 |
Calls: | 9,694 |
Calls today: | 4 |
Files: | 13,731 |
Messages: | 6,178,580 |