-
Notifications
You must be signed in to change notification settings - Fork 14
Py bindings ci #60
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
Py bindings ci #60
Conversation
140fecb
to
20bfbb0
Compare
These files should have never been commited to source. By removing these shared libraries we encourage developers to build from source instead of using this repo as a quasi package.
It's not compatible with venv.
20bfbb0
to
b6efb20
Compare
The version should, at least for now, without python-specific breaks, match payjoin-ffi/Cargo.toml
b6efb20
to
75a1e46
Compare
We should follow bdk-ffi's test-python GitHub workflow as an example |
907c629
to
d8a23f5
Compare
1095192
to
b12d171
Compare
I see BDK's generate scripts, at least the linux one for python do build the lib before running |
05ab71e
to
1e7b834
Compare
fcd0baf
to
ad80cee
Compare
Finally done wrestling CI. Major changes include:
|
The one thing I would hope for here is that the CI changes are squashed together so that intermediate commits won't fail the CI checks they implement |
Do you mean the changes needed to make CI pass? |
We depend on bitcoin-ffi now.
ad80cee
to
3d1a951
Compare
yes |
Moved the commit which adds the CI jobs as the last commit and squashed relevant commits. The other commits atomically fix different things, not neccecarily for CI. For example removing windows support and fixing the x86 MacOS binary. Even without the last commit we would want these and they achieve independently useful things. I could make a monster commit that fixes the various problems that exist in main and then a CI commit but I do think there is an added benefit to having seperate atomic commits. For instance we could revert just the commit that removes window support in the future. Let me know how you would proceed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the windows script entirely seems not to be done.
Otherwise this is looking pretty darn good
|
||
#!/bin/bash | ||
chmod +x ./scripts/generate_linux.sh | ||
chmod +x ./scripts/generate_windows.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you wish not also to remove the generate_windows script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agh Yeah this was done in a seperate commit. I will move that change to this commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
- name: "Build wheel" | ||
# Specifying the plat-name argument is necessary to build a wheel with the correct name, | ||
# see issue BDK#350 for more information | ||
run: python3 setup.py bdist_wheel --plat-name macosx_11_0_x86_64 --verbose |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we mention, as bdk does, the rationale for testing only the x86 wheel? https://github.com/bitcoindevkit/bdk-ffi/blob/master/.github/workflows/test-python.yaml#L97
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it could be worth having this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good comment. I actually realized that we are not building the arm64 wheel on CI. Will add this step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
python/scripts/generate_windows.sh
Outdated
cd ../ | ||
cargo run --features uniffi --bin uniffi-bindgen generate src/payjoin_ffi.udl --language python --out-dir python/src/payjoin/ | ||
|
||
cargo run --features uniffi --bin uniffi-bindgen generate --library target/release/$LIBNAME --language python --out-dir python/src/payjoin/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would seem this windows script should have been removed with its support a few commits earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes you are right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
The windows binding support has gotten stale and there is no demand for it. Supporting these bindings is not worth the overhead of maintaining them.
We need a release built *.so and *.dylib file before running uniffi-bindgen. Without the share object file the uniffi command will fail to find the shared object and error out. For example: https://github.com/LtbLightning/payjoin-ffi/actions/runs/14045076123/job/39323956701?pr=60#step:4:474
`setup.py` depends on toml.
Skipping any unit test that is currently broken due to FFI bindings. Issue to re-enable them: LtbLightning#62
3d1a951
to
afd45e4
Compare
New CI job to build and run python unit tests. This gh action workflow builds for MacOS x86 and arm archs. While only running the tests on an x86 machine.
afd45e4
to
57aabaf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK 57aabaf
Tested on macOS, it took a bit of fiddling with python to get the incantations right but got build and test passing with:
python3 -m venv pjvenv
source pjvenv/bin/activate
bash scripts/generate_macos.sh
python3 setup.py bdist_wheel --verbose
pip3 install ./dist/*.whl
python3 -m unittest --verbose test/payjoin_unit_test.py
----------------------------------------------------------------------
Ran 6 tests in 0.000s
OK (skipped=5)
@spacebear21 thanks for testing! Was this on an arm or x86 mac? |
Ah yes I should've specified, this was on ARM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack 76282f1
closes #3
closes #57