bytecodealliance
Language bindings for the WIT parser
People are going to want to parse WIT from other languages and I've already run into a case where it would be useful to have bindings in Python for writing a test generator. If we want to avoid having a bunch of different parsers in different languages that we have to keep in sync, it may make sense to provide language bindings for the WIT parser.
There are two main approaches
- we could use a language-specific method for each language (e.g. PyO3 for Python)
- we could use a multi-language generator to help (e.g. SWIG)
Does anyone have a preference for which option to choose?
There are some use cases that might want to parse a WIT file that aren't trying to generate bindings. For example, parsing a WIT file could enable people to make automatic fuzzing tools or integrate WIT files into other environments that can't statically generate the bindings. Wherever people are trying to statically generate language bindings, we should continue to develop wit-bindgen to meet those needs.
I mean for the wit-parser to use wit-bindgen to allow it to be used by other languages.
I see, yes we should do that at some point and distribute a WIT-based wasm module/component, but for now the ecosystem isn't at the point where people can nicely pip install a WIT+WASM module/component and have Python know how to spin up a runtime and instantiate it (wouldn't that be nice?).
So for now offering the parser as WIT+WASM using wit-bindgen involves either requiring the user to configure their own runtime (which is more work than they want) or picking a runtime in our package and spinning it up ourselves (which is probably too opinionated). That's why for now I think it would make sense to offer direct idiomatic language bindings that don't use wit-bindgen.
Personally I'm not aware of any off-the-shelf great solutions for binding easily into other languages from Rust. I don't think that dogfooding itself makes a ton of sense here since that still requires a wasm runtime in the target language which isn't always available.
Otherwise though it might be good to start with a C API perhaps and then other languages can be built on that? That's the main way that I'm aware of to integrate Rust into other languages.
At a high level though integrating one language with many others like this can often incur a lot of maintenance overhead. If possible I think it would be great to avoid that. One option would be to have a widely-available CLI tool (as wit-bindgen is in theory) which handles everything internally? For example wit-bindgen could have a mode that dumps an AST to JSON or something like that which could be easily picked up by other languages.
I believe that this is more applicable for the wasm-tools repository nowadays but I'm going to instead close this. I think that this should be grown naturally over time as necessary as opposed to proactively building this since I'm not aware of a great solution at this time.
That being said I sort of did this with the wasmtime-py generator where the wit generator, written in Rust, is exposed to Python through itself. That is, when generating Python bindings, it's running a wasm binary compiled from Rust. That may or may not be a great way forward for other languages as well, which is why I'm closing this for now to instead consider this on a case-by-case basis.