Open bibi21000 opened 7 years ago
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
Should we change ? Use one ? Many ?
cython :
pybind :
cffi :
many : develop a "common interface" to all backends and a way to use the right one (using flavors)
Users advices See #93