cython, pybind and cffi

[bibi21000]

Should we change ? Use one ? Many ?

cython :

• hard to install ( see #2 )
• allow embed packages
• stable

pybind :

• See #59

cffi :

• https://github.com/Julian/libopenzwave-cffi

many : develop a "common interface" to all backends and a way to use the right one (using flavors)

• stable
• others plateforms ? ie Android ?

Users advices See #93

[NotTheEvilOne]

Dear @bibi21000, dear developers,

After some other projects being finally finished I had a look at what changed for "python-openzwave" since #59. Fortunately for the pybind11 implementation (which was mostly finished in February) not that many things changed.

The new Makefile and setup.py look even more overloaded thought. I wonder how I could support the development for "python-openzwave" the best way.

After digging around at the changes of command.py and node.py I really want to implement a generic way to include only interfaces a physical Z-Wave node has and a new callback system to have an extendible platform in Python for future improvements.

Here are the options I see so far (please don't be irritated, I'm here for discussion):

• Update my fork and send a PR for you that can be branched as "develop 1.0.0" as API need to change. -- with a cleaned up setup.py (providing lib-only installation via e.g. setup.py --install-platlib) -- change C++ code to pybind11 for easier, better maintainable and since 2.1.0 of pybind11 even iteratable enums -- with all the Python changes, including the cleaned up Z-Wave nodes only providing interfaces they actually have, for easier enhancements and support of new Z-Wave classes. -- kick out all deprecated and scary stuff like circular dependencies between network and controller, the broken pyozwweb, the old and long forgotten louie dependency (or at least capsulate it) etc. -- Ask you to maybe move the manager code to a separate project as the library has nothing to do with a helpful but large-scale demo console application IMHO.

• Throw away all platform specific C++ code (as shared builds are finally possible) and send in a PR with the Python API changes discussed in #59. I would still recommend to break the API at this point as some old decisions like using static methods as instance methods (e.g. manager.getPythonLibraryVersionNumber() instead of PyManager.getPythonLibraryVersionNumber() and various create() / destroy() ones) made it already hard last time to implement the same API in pybind11.

• Do a fork as pyozw and start from scratch with the first option.

What do you think would be the best option for the Python-bindings for OZW?

Best regards Tobias