search

apmorton / pyhidapi

hidapi bindings in ctypes
MIT License
111 stars 42 forks source link

README: point to libusb/hidapi repository #29

Closed Qbicz closed 5 years ago

Qbicz commented 5 years ago

HIDAPI has been moved to libusb/hidapi and is again maintained. Updated the links to the new repository.

Signed-off-by: Kubicz, Filip Filip.Kubicz@nordicsemi.no

Qbicz commented 5 years ago

See https://github.com/libusb/hidapi and https://github.com/signal11/hidapi/issues/373

apmorton commented 5 years ago

It seems you are a maintainer of this new hidapi fork?

Is there any interest in merging this python wrapper into the new fork for continued maintenance there?

I would happily do this and add any maintainers over there to the pypi package as maintainers.

It does seem there are a multitude of python wrappers for hidapi, and maybe it would be nice to standardize on one.

Back when I started this wrapper building binary modules for python was a major pain in the butt to do cross platform - but this isn't really the case anymore, and since we now have bdist_wheel, distribution of binary modules on pypi is really nice. Maybe this ctypes wrapper has run its course, and building a native module for each platform that doesn't rely on a separately distributed shared library would be a nicer solution overall.

In any case, if the new hidapi maintainers want to take ownership of this pypi package name - whether for the existing ctypes implementation or a rewrite into a native module - I would be happy to cooperate.

Qbicz commented 5 years ago

Thank you @apmorton for accepting this change! For me, pyhidapi ctypes wrapper is a reliable solution. I have not observed the ctypes calls to be a bottleneck of any kind during communication with HID devices (I used feature reports mostly).

On the other hand, having Python module with integrated library sounds interesting, but wouldn't it mean bigger maintenance burden? Can you elaborate a bit on how bdist_wheel helps creating cross-platform versions?

@youw @todbot @z3ntu @jdk what do you think, would you support merging the Python wrapper to HIDAPI, or should it stay a separate project?

Youw commented 5 years ago

It does seem there are a multitude of python wrappers for hidapi, and maybe it would be nice to standardize on one.

Is there any interest in merging this python wrapper into the new fork for continued maintenance there?

I think that is a good idea, to have a python wrapper as part of original hidapi repo

good question - who is going to maintain python part (for instance, I don't consider myself a good option for such, for several reasons), but it seems, that @apmorton had already agreed to take that part

my other concern - this implementation is using ctypes as underlying mechanism for wrapping a hidapi C library, and quick googling shows that there is at least one alternative: cython, which claimed to be more efficient in terms of overhead I haven't perform a deep comparison of all pros and cons, but I think it at least worth to be discussed

a big proc to go with pyhidapi as is it is - it is actually working and release to PyPI

Qbicz commented 5 years ago

After giving it a thought, I believe it is better not to merge pyhidapi into hidapi. I see two reasons:

  1. Python wrapper is separate project from C library. It can have a separate repository. This way we have a clear separation of concerns.
  2. Some projects use pyhidapi ctypes wrapper, while others use Cython wrapper. Everyone is free to choose the option they want, some people don't use Python but other languages, there is C# wrapper or Rust wrapper. Merging one of these but not the others would be confusing.
Youw commented 5 years ago

good thinking, agree