Module name conflicts with official bindings

[Gadgetoid]

Is there a reason why this package conflicts the "gpiod" module name?

The official python bindings are now available as "libgpiod" via pypi, and provide a "gpiod" module. They are currently broken, but I'm looking into repackaging in such a way that the official bindings are widely accessible to the Python community and proffering up a patch to Bart in the hopes we can get them sorted.

However when I "import gpiod", or write code that does so, I have no guarantee if I get the official bindings or yours. The current state of deb packages vs Python bindings, venvs versus not venvs and various broken packages means I am writing defensive code like this:

if hasattr(gpiod, "chip")       # gpiod
   ...
elif hasattr(gpiod, "Chip"):    # libgpiod
   ...

Which isn't great, because gpiod is about 2-3x slower than libgpiod for raw GPIO toggle throughput, so they are not totally equivalent.

There exists an "smsbus" pure Python package that used the name "smbus2" to work around this, and I humbly suggest that "gpiod" - this library - adopts something like this and renames the module to avoid conflicts.

Since it's not reasonable to expect that the official Python bindings step aside for a pure-Python alternative (though, in some ways I'd prefer that was the case), perhaps renaming this module is appropriate?

[Gadgetoid]

Teaching me to not look before I leap, of course my suggestion of "pygpiod" is already yet another gpiod module and - ironically -it's just Python bindings around libgpiod which means it starts with import gpiod which would import this library and break if it were installed instead of (or in a venv shadowing) the official bindings 🙄

https://github.com/gustavsl/pygpiod/blob/c5c4af51f58d09285e63d367db6b6aeff686acb2/pygpiod/pygpiod.py#L1

Though it looks like that library is probably unmaintained, and might even respond well to asking to be supplanted with this one.

Though, following convention from the official package, perhaps this library should be called "pylibgpiod" and supply the module "pygpiod".

[hhk7734]

HI @brgl

I invited you to pypi gpiod project as an owner.

I released gpiod up to version 1.5.4, but I'm no longer working in the embedded systems industry and I don't think I'll be able to maintain this package. I just found out that the 2.0.1 version has been uploaded to PYPI, so I'm thinking of handing over ownership. what do you think?

[hhk7734]

@Gadgetoid

I was planning to abandon pure Python modules and switch to libgpiod2 + pybind11 starting with version 2 due to the difficulty of maintenance. However, if @brgl takes ownership, I'm considering moving this repo to a public archive.

[Gadgetoid]

I'm in the process of working on some patches to get the official bindings up to spec, so they could very well replace this library. Though I'm wary of how that might cause an API break to existing users- if there are any/many?

Right now there's your Python API, the old libgpiod API and the new libgpiod API and scant documentation or examples so I strongly suspect uptake hasn't been great.

If you're still at all interested in embedded GPIO, I'd appreciate your feedback on my changes here, which I need to formally submit upstream: Gadgetoid/libgpiod#2

Edit: I must add, I appreciate your responses and willingness to help here- I've been losing some sleep over getting GPIO into a sensible state to migrate our libraries and set an example for Raspberry Pi users. Thank you!

[hhk7734]

@Gadgetoid this package use signatures like libgpiodcxx.so. So v1 of the official python binding was incompatible with this package. I haven't seen the official v2 binding signatures, but if they haven't changed significantly, people who were using this package will need to modify their code.

[brgl]

Hey! Thanks for inviting me as owner of the pypi package. I admit that Python bindings have not received enough of my attention, mostly due to the fact that I'm mainly a kernel developer. I mostly focus on the low-level plumbing part which is the libgpiod C library.

@Gadgetoid is doing a great job of making the official bindings more user-friendly.

Just to clarify the situation: libgpiod has two major versions with incompatible APIs. The v1.6.x series is still maintained, though it's not getting new features. Libgpiod v2.0.2 is the current release and it's still being developed and extended (e.g. with the upcoming DBus API). The reason for a new major release is the fact that v1 was not capable of supporting new kernel GPIO uAPI features that were released in linux v5.16. We had to design something more future-proof and it was not possible without breaking the API.

The problem right now is that most distros only package libgpiod v1, while the official bindings from pypi require v2. Hence @Gadgetoid 's work.

I don't have nearly enough knowledge of distro packaging nor any spare time to figure it out. As an embedded linux dev, I'm mostly concerned about yocto and this is what I personally support and keep up to date. Everything else is third party.

I hope that clarifies the situation a bit. Thanks for the help!