search

openwsn-berkeley / lakers

EDHOC implemented in Rust, optimized for microcontrollers, with bindings for C and Python.
https://crates.io/crates/lakers
BSD 3-Clause "New" or "Revised" License
13 stars 10 forks source link

lakers-python: Build also for pypy #288

Closed chrysn closed 1 month ago

chrysn commented 3 months ago

The wheels uploaded for lakers-python do not contain wheels for pypy; this means that pypy hosts have to have a local Rust installation to install it.

It's not a big deal, but I think it should be tracked (it may be related that it's a workaround I put into the aiocoap build scripts that increases CI times, and I am in the habit of associating workarounds to a link to what they are working around ;-) ).

I have had a brief look at my own maturin "reference" project, cbor-diag, which has pypy builds, and I don't even remember ever having done anything to make that work, but I'll have another look to see whether this can be fixed easily.

geonnave commented 3 months ago

I think I initially restricted the build to (C)Python 3.{10, 11, 12} to based on this table, trying to balance build time and potential demand from users.

Which version of pypy should I add to the build? Based on this, I am not sure how is the support of GitHub Actions to newer Python versions on pypy (btw I am not familiar with pypy).

chrysn commented 3 months ago

10, 11, 12 is a good set at the moment. (Adding 3.13 could be nice soon, I may give that a test run).

The one thing I can tell you about users is that running on pypy3.10 is what I do on aiocoap's CI (which is where I noticed this). Personally I build on pypy as a check against cpython-isms (which admittedly lakers won't need, taking from pyo3, but the whl builds are for the downstreams).