-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python wrapper needs pyproject.toml #1000
Comments
It turns out that the pyRF24/crossunixcompiler.py script is only there for cross-compiling the python wrapper (instructions are for python v2). I don't think this works anymore because the CPython headers ( I'm confident enough to remove the custom build script and update the wrapper to use a pyproject.toml. I think we should also remove the cross-compiling python instructions from the docs too. PS - The |
Oh, I just realized this is ticket number 1000! |
note this removes the old cross compile script (for unix) ref #1000
In reviewing the setup.py code for the 3 individual wrappers, I found a way to link to It involves getting the major and minor versions of the python interpreter used for installation. Lines 76 to 78 in a8fe7cf
This improvement makes the following documented instruction obsolete Line 68 in 5e89cc8
|
note this removes the old cross compile script (for unix) ref #1000
note this removes the old cross compile script ref #1000 * update docs
I just installed the python wrapper to test a branch's changes, and I got the following message:
Should we maintain it?
I'm not sure if it is worth updating since we have the pyRF24 package which already complies with the latest approved/enforced PEPs. The only advantage in maintaining the individual wrappers is for outdated python versions: Any Python version below v3.7 would need to use individual wrappers.
Important
Python v3.7 is already at End-of-Life (just like Python v2.x). Python v3.8 is about to hit EoL in Oct 2024. See python version lifecycle page.
The pyRF24 package requires at least Python v3.7 for various reasons. The only unavoidable reason is that it is using pybind11 (requires v3.7 minimum) instead of boost.python (which seems less actively maintained nowadays).
Any complications?
The main problem here is that the individual wrapper uses a custom build script that drives the compiler: pyRF24/crossunixccompiler.py. I doubt that this is needed anymore, but I haven't looked into it for a few years. I'm also afraid that removing the build script and opting for the recommended/builtin functionality offered by the
setuptools
package might break very old python versions.The text was updated successfully, but these errors were encountered: