8000 support bleak 0.19.0 and up by dhalbert · Pull Request #58 · adafruit/Adafruit_Blinka_bleio · GitHub
[go: up one dir, main page]

Skip to content

support bleak 0.19.0 and up #58

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

Merged
merged 2 commits into from
Apr 3, 2023
Merged

Conversation

dhalbert
Copy link
Contributor
@dhalbert dhalbert commented Apr 3, 2023

The bleak version was pinned to 0.11.0 in the early days of this library, when bleak was undergoing a lot of API churn. That may have also prevented advancing the supported Python version (the guide recommended Python 3.8). There have been many changes, fixes, and improvements to bleak since then. As an example, the Windows backend now uses a different lower-level lirbrary.

Updated to handle API changes in bleak from 0.19.0 on.

Tested using adafruit_ble_heart_rate with bleak 0.20.1, on Linux, macoS 13.2.1 and 13.3, Windows 10, and Windows 11, with Python 3.10.x and 3.11.x. Works on all, except that on Windows, the default timeout for BLERadio.connect(), which is 4 seconds seems to be too short at least some of the time. I increased it to 10 seconds and it connects successfully. Once it has connected once, further connects are faster. I may change the timeout there after this is released; at the very least I will document the issue in the Learn Guide, https://learn.adafruit.com/circuitpython-ble-libraries-on-any-computer.

EDIT: Tested on latest RPI bullseye as well. Works, after lengthening connection timeout to 10 seconds, as I had to do for Windows. This confirms it's a good idea to change the default.

Fixes #41.
Fixes #45.

@dhalbert dhalbert requested a review from a team April 3, 2023 00:55
@dhalbert
Copy link
Contributor Author
dhalbert commented Apr 3, 2023

@tekktrik This library is like blinka: it will never be a .mpy bundle library. However, at some point its build.yml was set up to do the standard stuff like build mpy-cross, etc. Then it was never converted to composite actions, and it started failing because the mpy-cross part was doing trying to do sed on nvm.toml, which was not a file but a submodule.

I changed it to your composite actions for this PR so the build did not fail, but I wonder what the right thing to do here is. The Blinka library is not a great example here because it doesn't even use pyproject.toml, for backward compatibility reasons, I believe.

Also tagging @makermelissa here for ideas

@tekktrik
Copy link
Member
tekktrik commented Apr 3, 2023

I think the composite actions are great for the many libraries that will always use the same build process because it also ensures that they're updated consistently and simultaneously. Since that may actually not be the desired effect here, I don't think it's wrong to have custom CI workflows for libraries like this. With those composite actions it means that doing these ones manually is much more feasible.

Alternatively we could make it possible for the composite actions to not build the bundle, but I think the aforementioned solution is better.

Another option is to break out the composite actions further into smaller puzzle pieces that can be used here, but I think that might result in a lot of very small pieces of workflow code that could be just as hard to manage as just manually patching repos like this one.

@dhalbert
Copy link
Contributor Author
dhalbert commented Apr 3, 2023

@tekktrik Thanks for the comments. I have restored the original workflow files and removed unnecessary steps from it.

Copy link
Member
@tannewt tannewt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Difficulty installing on Windows common.py throws a FutureWarning from bleak call to get_discovered_devices
3 participants
0