Conversation
| @@ -0,0 +1,66 @@ | |||
| # This file is automatically generated by pyo3_stub_gen | |||
There was a problem hiding this comment.
Do we need to include this file in the source code of this package?
There was a problem hiding this comment.
I kept this file in version control to have a history of the Python API, in case we need to troubleshoot API changes. Old code that relies on a specific API that we break in a future version.
We can still do the same thing generating the file for every version we want to check but it's easier to browse if it's here
And since we're using an external dependency to generate this file, might be helpful if the dependency changes it's behavior in the future
Do you see any significant drawback of having this file here?
There was a problem hiding this comment.
that's ok, just making sure it's not been forgotten
| thiserror = "2.0.12" | ||
|
|
||
| [profile.release] | ||
| lto = "fat" No newline at end of file |
There was a problem hiding this comment.
Do we need this LTO change?
There was a problem hiding this comment.
Not really, I was testing this when I was addressing the performance issues but this didn't have any effect on performance
Will remove it 👍
This PR will introduce Python bindings for the
ooniauth-corecrateThe bindings are implemented in the
ooniauh-pycrate, usingpyo3and maturin to make the bindingsMy main goals with this crate were:
ooniauth-core, so that the usage of the library is driven by that crateUserStateclass for testing with PythonIn the following repo I provide a minimal fastapi project to show how the library will be used in Python: https://github.com/LDiazN/anoncred/blob/main/tests/test_creds.py (Still WIP)
Note: the fastapi project assumes that you have the library installed in your virtual environment, this is due to how the maturin workflow works (it assumes that you are running in a virtualenv, and during development it installs the preview library in that virtualenv)
Feedback
The intention with this first iteration is to lay the foundational work to direct the development of the bindings library, so all the feedback is welcome
That said, here are some things that I think might need a bit more thought:
to_binandto_strconversions for transfers. This is because we're usingjsonas encoding, so we could change the encoding to keep the bytes interface if we really need it, but if there's no reason to keep it, I would say we change it to a string interface (and it's probably more efficient to do those conversions in Rust land anyways)closes #6