Hi from the Conan team!

We recently released conan-py-build, a PEP 517 build backend that uses Conan to manage C/C++ dependencies, and we're testing it on several popular Python extensions that we think could benefit from it.

Here's the launch blog post: https://blog.conan.io/cpp/conan/python/2026/05/05/Introducing-conan-py-build.html
And the repo and docs: https://github.com/conan-io/conan-py-build · https://conan-py-build.conan.io/

We wanted to share this port of py-tree-sitter to conan-py-build to get some comments and feedback from the project. The tree-sitter C library is fetched from Conan Center Index instead of a git submodule.

Also, the CI workflows have a few tweaks for testing in our fork, but just ignore those, they wouldn't be part of a real PR.

Note on version: this branch tests against 0.26.9, the latest version available in Conan Center. We also verified it against 0.25.1 for a direct comparison with the published PyPI release.

Some notes about the migration:

• No submodule. The tree-sitter C library is fetched by Conan at build time.

• Explicit, versioned C dependency. Conan resolves tree-sitter/<version> from Conan Center Index. Bumping the C library is a one-line change in pyproject.toml.

• Standard CMake build. CMakeLists.txt is a plain CMake project.

• Same CI workflow. cibuildwheel keeps driving the multi-platform builds with minimal changes. All 7 platforms pass (linux x86_64/aarch64, musllinux x86_64, macOS arm64/x86_64, Windows amd64/arm64).

• Equivalent wheels. We compared the output against the 0.25.1 PyPI release file-by-file across all platforms. The only differences are cosmetic metadata.

CI results:

Any feedback is very welcome

Thanks a lot! 🙂