I've been keeping `ty-extended` in sync with upstream `ty`, and a few days ago I thought probably the slow adoption of it was that one needed to write the plugins in Rust.
Also, pure Python codebases that need to have custom private plugins would need to add the extremely slow Rust compile times to their CI workflows.
Today I added Pydantic's Monty that supports a Python subset that IMO is sufficient for supporting the plugin sdk. The limitations are the same everyone has writing code for Monty, but it is now much easier to create plugins in a few steps, without compilation, etc.
Also, pure Python codebases that need to have custom private plugins would need to add the extremely slow Rust compile times to their CI workflows.
Today I added Pydantic's Monty that supports a Python subset that IMO is sufficient for supporting the plugin sdk. The limitations are the same everyone has writing code for Monty, but it is now much easier to create plugins in a few steps, without compilation, etc.
You can check how it works with a toy example, which implements a "mini Django" to prove both WASM and Monty runtimes work as expected: https://github.com/regularkevvv/ty-extended/tree/main/exampl...
Lmk any feedback!