bibi21000
commented
7 years ago Hi folks,
Hi
I would like to start a discussion about a rework of the libopenzwave integration based on pybind11 which I started as a experiment on this branch.
I'm Ok with that. Cython causes a lot of troubles. I've look at cffi in the past but need a lot of work ...
Main advantages I see so far are:
Significantly smaller code base required for the C++ integration (1885 to 5534 lines). Added functionality for openzwave structs (like Driver and Node statistics) Replaced magic numbers with there enum equivalents Fixes to some Manager methods like underlining the meaning of "getValueListSelectionItem" and "getValueListSelectionValue" as well as getValueList equivalents. Fixes for some bugs like destroy methods not being static or create singleton methods hidden behind a Python constructor Minimal breakage (but major version update would be needed) of existing API accessing libopenzwave directly
Keep in mind that some Home automation projects use the api (home-assistant, jeedom) but other the lib (domogik). It should be nice to minimize the update process for all. And of course document it. Disadvantages:
C++11 is required but should be available on all current platforms by now anyway Actually supported plateforms are Ubuntu (and others linuxes), OSX, Windows and raspberry under python 2.7 and python3. Code relying on somehow broken libopenzwave PyManager and PyOptions constructors (which are not underlining the underlying singleton implementation) are doomed and would need changes including the class names being changed. This can be discussed of course. enums are not iteratable. openzwave must redefine them as dicts or classes if needed I would like to continue contributing changes for the Home Assistant project based on ArchLinux AUR. Therefore a dynamic linking build including the possibility to use "make DESTDIR=.. install" would be required to create packages. Furthermore maintenance is easier if a platform /usr/lib/libopenzwave.so can be used with /etc/openzwave no matter if C++ or the Python integration is used and build. This was somehow added as DEBIAN_PACKAGE before. But there is a problem with cython, what about pybind :https://github.com/OpenZWave/python-openzwave/issues/54
There are currently a number of open issues like broken src-api implementation which I continue to fix while this discussion takes place.
I would highly appreciate your input about the route taken and if the upstream project would be interested in taking advantage of these changes.
As mentioned before, cython causes me a lot of trouble so it should be a good thing to remove it. But python-openzwave is used in a lot of project (about 1700 unique cloners for 15 days in github statistics), so there will be a lot of people impacted with these modifications on many plateforms. There is a testsuite in python-openzwave (look at makefile), it can be helpfull An other point : cython can create a cpp file that can be embeded in the archive with the static lib (.la). Can pybind do the same. This is really usefull on a raspberry (divide installation process by 5)
NotTheEvilOne
robbiet480
Hi folks,
I would like to start a discussion about a rework of the libopenzwave integration based on pybind11 which I started as a experiment on this branch.
Main advantages I see so far are:
Disadvantages:
I would like to continue contributing changes for the Home Assistant project based on ArchLinux AUR. Therefore a dynamic linking build including the possibility to use "make DESTDIR=.. install" would be required to create packages. Furthermore maintenance is easier if a platform /usr/lib/libopenzwave.so can be used with /etc/openzwave no matter if C++ or the Python integration is used and build. This was somehow added as DEBIAN_PACKAGE before.
There are currently a number of open issues like broken src-api implementation which I continue to fix while this discussion takes place.
I would highly appreciate your input about the route taken and if the upstream project would be interested in taking advantage of these changes.