wasmtime / Issue #1390 Home for language bindings for was... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / Issue #1390 Home for language bindings for was...

Wasmtime GitHub notifications bot (Mar 24 2020 at 14:41):

alexcrichton opened Issue #1390:

I've been thinking recently about the Python and .NET bindings for wasmtime we have in this repository right now (crates/misc/py and crates/misc/dotnet). These two are wildly different from each other, mostly because of when they were written. The Python extension uses pyo3 to mostly write Rust code and give a Python interface, whereas the .NET extension uses the C API of wasmtime exclusively. Additionally the .NET extension is much more full-featured compared to the Python extension, which currently mostly only has bare-bones support for loading modules.

I think that the Python extension is overdue for a rewrite, but I wanted to also take the opportunity to discuss a bit what we see as the future of these language bindings. I think there's a few things to consider when thinking about other language bindings:

Python/.NET are not the last languages, we're going to want to expand somehow. Having everything in one repository isn't necessarily scalable because CI will eventually become pretty burdensome, and we may not want to have as strict repository permissions around language bindings.

I think we should strive for as much uniformity as we can across all language support. The Rust API will always be the source, but I think everything else should strive to basically provide the Rust API (as translated to the native language), but implemented through the C API.

Documenting these extensions may be a bit tricky in the main repo. Ideally we'd have examples from all languages to show off, but if they're living in separate repos we may have to do some small sync'ing.

I would personally propose the following plan of action for our bindings:

Move the Python/.NET bindings out of this repository. For example bytecodealliance/wasmtime-dotnet and bytecodealliance/wasmtime-python.

Rewrite the Python extension to use the C API (likely with ctypes or cffi, I'm not exactly a Python afficionado).

Set up independent release processes for each extension (probably just document it for now)

Set up local documentation for each extension (likely mdbook), and link the main wasmtime mdbook to this documentation.

I personally don't think there's much of a future where everything lives in this repository since it feels like we'd clog things up too much, and given the stability of the C API I think it's pretty reasonable to build the extensions and maintain them externally.

I'm curious what others think about this though!

Wasmtime GitHub notifications bot (Mar 24 2020 at 14:41):

alexcrichton labeled Issue #1390:

I've been thinking recently about the Python and .NET bindings for wasmtime we have in this repository right now (crates/misc/py and crates/misc/dotnet). These two are wildly different from each other, mostly because of when they were written. The Python extension uses pyo3 to mostly write Rust code and give a Python interface, whereas the .NET extension uses the C API of wasmtime exclusively. Additionally the .NET extension is much more full-featured compared to the Python extension, which currently mostly only has bare-bones support for loading modules.

I think that the Python extension is overdue for a rewrite, but I wanted to also take the opportunity to discuss a bit what we see as the future of these language bindings. I think there's a few things to consider when thinking about other language bindings:

Python/.NET are not the last languages, we're going to want to expand somehow. Having everything in one repository isn't necessarily scalable because CI will eventually become pretty burdensome, and we may not want to have as strict repository permissions around language bindings.

I think we should strive for as much uniformity as we can across all language support. The Rust API will always be the source, but I think everything else should strive to basically provide the Rust API (as translated to the native language), but implemented through the C API.

Documenting these extensions may be a bit tricky in the main repo. Ideally we'd have examples from all languages to show off, but if they're living in separate repos we may have to do some small sync'ing.

I would personally propose the following plan of action for our bindings:

Move the Python/.NET bindings out of this repository. For example bytecodealliance/wasmtime-dotnet and bytecodealliance/wasmtime-python.

Rewrite the Python extension to use the C API (likely with ctypes or cffi, I'm not exactly a Python afficionado).

Set up independent release processes for each extension (probably just document it for now)

Set up local documentation for each extension (likely mdbook), and link the main wasmtime mdbook to this documentation.

I personally don't think there's much of a future where everything lives in this repository since it feels like we'd clog things up too much, and given the stability of the C API I think it's pretty reasonable to build the extensions and maintain them externally.

I'm curious what others think about this though!

Wasmtime GitHub notifications bot (Mar 24 2020 at 14:41):

alexcrichton commented on Issue #1390:

cc @peterhuene, @tschneidereit

Wasmtime GitHub notifications bot (Mar 24 2020 at 18:35):

peterhuene commented on Issue #1390:

I think separating them out into their own BA repos makes sense, especially regarding the CI tax.

I also agree that the Python implementation should probably use the C API via FFI, as well as future supported languages.

Currently the .NET projects build the local Wasmtime as part of the build process, but it wouldn't be that hard to refactor that to either provide a location of the Wasmtime libraries via a variable and perhaps default to pulling down a particular dev snapshot or official release (for tagged builds of the .NET NuGet package) from GitHub.

Wasmtime GitHub notifications bot (Mar 24 2020 at 18:35):

peterhuene edited a comment on Issue #1390:

I think separating them out into their own BA repos makes sense, especially regarding the CI tax.

I also agree that the Python implementation should probably use the C API via FFI, as well as future supported languages.

Currently the .NET projects build the local Wasmtime C library as part of the build process, but it wouldn't be that hard to refactor that to either provide a location of the Wasmtime libraries via a variable and perhaps default to pulling down a particular dev snapshot or official release (for tagged builds of the .NET NuGet package) from GitHub.

Wasmtime GitHub notifications bot (Mar 24 2020 at 18:36):

peterhuene edited a comment on Issue #1390:

I think separating them out into their own BA repos makes sense, especially regarding the CI tax.

I also agree that the Python implementation should probably use the C API via FFI, as well as future supported languages.

Currently the .NET projects build the local Wasmtime C library as part of the build process, but it wouldn't be that hard to refactor that to either provide a location of the Wasmtime libraries via a variable and perhaps default to pulling down the latest dev snapshot or a particular official release (for tagged builds of the .NET NuGet package) from GitHub.

Wasmtime GitHub notifications bot (Mar 24 2020 at 18:39):

peterhuene commented on Issue #1390:

I've also snagged the bytecodealliance organization on NuGet since I think we should start publishing the .NET packages there rather than to my own personal one.

Wasmtime GitHub notifications bot (Mar 24 2020 at 20:30):

pchickey commented on Issue #1390:

Oh that explains why I got NuGet email on the bca list. I marked it as spam. sorry MS :(

Wasmtime GitHub notifications bot (Mar 24 2020 at 20:36):

peterhuene commented on Issue #1390:

Sorry about that. The email address for the NuGet organization is also the contact email, unfortunately. I've configured it to reduce the spam going forward.

Wasmtime GitHub notifications bot (Apr 07 2020 at 01:04):

alexcrichton commented on Issue #1390:

Bindings are now moved out!

Wasmtime GitHub notifications bot (Apr 07 2020 at 01:04):

alexcrichton closed Issue #1390:

I've been thinking recently about the Python and .NET bindings for wasmtime we have in this repository right now (crates/misc/py and crates/misc/dotnet). These two are wildly different from each other, mostly because of when they were written. The Python extension uses pyo3 to mostly write Rust code and give a Python interface, whereas the .NET extension uses the C API of wasmtime exclusively. Additionally the .NET extension is much more full-featured compared to the Python extension, which currently mostly only has bare-bones support for loading modules.

I think that the Python extension is overdue for a rewrite, but I wanted to also take the opportunity to discuss a bit what we see as the future of these language bindings. I think there's a few things to consider when thinking about other language bindings:

Python/.NET are not the last languages, we're going to want to expand somehow. Having everything in one repository isn't necessarily scalable because CI will eventually become pretty burdensome, and we may not want to have as strict repository permissions around language bindings.

I think we should strive for as much uniformity as we can across all language support. The Rust API will always be the source, but I think everything else should strive to basically provide the Rust API (as translated to the native language), but implemented through the C API.

Documenting these extensions may be a bit tricky in the main repo. Ideally we'd have examples from all languages to show off, but if they're living in separate repos we may have to do some small sync'ing.

I would personally propose the following plan of action for our bindings:

Move the Python/.NET bindings out of this repository. For example bytecodealliance/wasmtime-dotnet and bytecodealliance/wasmtime-python.

Rewrite the Python extension to use the C API (likely with ctypes or cffi, I'm not exactly a Python afficionado).

Set up independent release processes for each extension (probably just document it for now)

Set up local documentation for each extension (likely mdbook), and link the main wasmtime mdbook to this documentation.

I personally don't think there's much of a future where everything lives in this repository since it feels like we'd clog things up too much, and given the stability of the C API I think it's pretty reasonable to build the extensions and maintain them externally.

I'm curious what others think about this though!

Last updated: Dec 23 2024 at 12:05 UTC