Our python stubs (which provide full type information for our python bindings) currently lives as a separate file checked into the repo, which must be regenerated and re-committed any time the Python bindings change.
Now that we've switched to nanobind, I think we can use its built-in stubgen to generate them correctly and automatically every time we build the bindings, rather than being a separate checked-in file that could fall out of sync.
Our python stubs (which provide full type information for our python bindings) currently lives as a separate file checked into the repo, which must be regenerated and re-committed any time the Python bindings change.
Now that we've switched to nanobind, I think we can use its built-in stubgen to generate them correctly and automatically every time we build the bindings, rather than being a separate checked-in file that could fall out of sync.