Open pohutukawa opened 5 years ago
We'll want this ourselves probably, and maybe someone at Parity already did roughly this, like as part of schnorrkel-js, but regardless I'm probably not the best person for this task. I'm happy with a pull request for whatever the appropriate change should be. :)
cc @Kianenigma
I maybe miss-interpreted this as being about js, for which you likely want https://github.com/paritytech/schnorrkel-js/ but actually you just need some build types turned on? Is adding that bit to Cargo.toml all I do? Or do I need to any tests or CI stuff?
At least the path that we take on shcnorrkel-js was (obviously) to compile the main lib to Wasm and write a wrapper for it in Javascript. Not sure if that will be of any help when it comes to using it in python (might be worth googling though: how to execute wasm blob from python). Otherwise, this is an interesting issue that can be valuable for schnorrkel, yet it does not have much to do with the javascript related work.
Update: related? https://github.com/wasmerio/python-ext-wasm
I rushed my last comment. I meant: Are you asking for C bindings? I'm not exactly sure how rust hooks to js and if that requires some C-like bindings on the rust side. If so, maybe those could be abstracted from the schnorrkel-js code?
OK, some further feedback from our side. I've got quite some experience in wrapping (mainly C) libraries to Python. There once you've got the shared lib, things become quite easy. However, this is a different beast, and it's not C but rather Rust.
Due to this, there will be some enhanced need for wrapping things, just as @burdges has stated, e.g. in the schnorrkel-js
case.
Now, I can see two approaches in principle, that will both require in certain areas similar, but in other respect different approaches. A libschnorrkel
can be wrapped and made accessible via these methods:
ctypes
or CFFI
. Obviously there are also other alternatives like SWIG or others, which I'm not going more deeply into here (which I'm also not really considering for now).schnorrkel
functionality to a library. It should be very similar in principle to the schnorrkel-js
approach. However on execution then it would require a fully fledged WASM runtime (in whichever language, e.g. Python). However, such a runtime will weigh in severely in additional 'weight' (code deployment and overhead), which is quite cumbersome, unless one is already in need of doing 'WASMy stuff'.We're right now looking into doing another Rust 'project' (I believe it's called a 'crate' in Rust lingo), which will depend on the schnorrkel
crate. In this one then we're wrapping the functionality (similarly to and inspired by schnorrkel-js
) to procedural wrappers (unmangled and exported), which then will be compiled to a shared library that is basically C compatible. We'll look at wrapping that one then to be called into by Python.
I suppose an approach like this may be also a simple way to go for other high level languages. So I'm open to suggestions for improvement or further usage downwind. For simple use, the WASM approach is a bit 'heavy' in many cases that are more generic.
One quick attempt for python binding: https://github.com/holygits/schnorpy
We've made a first cut of a PyO3 wrapped Python library. Packaging/building is still the most sore point. And not the entire schnorrkel
functionality is wrapped. But feel free to have a look:
https://gitlab.com/kauriid/schnorrpy/
I want/need to use schnorrkel signing in another project. However the project is non Rust (Python), so I would like to be able to just compile it to a shared library, which I then can (hopefully) wrap using either Python's built-in
ctypes
or CFFI.However, I haven't found a
dynlib
orcdylib
directive anywhere that would result in it. Someone more familiar with Rust has told me to add the following to theCargo.toml
file to accomplish this. Though, for future code distribution reasons I'm hesistant to the need of patching code after cloning it from the repo to generate a Python package.Would it be possible to empower the code in this
schnorrkel
repo to allow for building a shared library out of the box?