py-tree-sitter

py-tree-sitter copied to clipboard

Is it possible to build this for Windows with gcc instead of downloading the big Microsoft package?

I will likely try to build binary wheels of tree_sitter for windows, mac and linux. They could then be installed without needing to have a C compiler. Then, together with py-tree-sitter-languages, it would be possible to use py-tree-sitter without a C compiler.

I can make a pull request to this repo, or if I don't hear back from the maintainers in a week or so, I'll probably just publish it on pypi as a separate package.

I have now created https://github.com/Akuli/py-tree-sitter-builds. Right now it's a pain to use as it isn't published on pypi. I'll probably put it to pypi if I still don't hear back from the maintainers of py-tree-sitter in a few days.

I will likely get around to an official compiled package with languages embedded but I don't see an issue with posting an alternative on pypi in the interim. To reduce future conflict you might want to use a different import name though.

Feel free to borrow my github actions config when you get around to this, or just ask me to make a pull request :)

Regarding import names: I think using the same import name is better. This way I don't need to also publish my own versions of various other packages (py-tree-sitter-languages, types-tree-sitter, types-tree-sitter-languages) that have tree_sitter hard-coded, and getting rid of my temporary package will be easier too. If someone is seriously still installing everything globally onto their system, it's their problem and they should start using virtualenvs :)

Ok, then I'd prefer to see if we can get upstream pypi packages published soon instead of you moving forward.

It looks like we have an arm64 Mac wheel being published already from somewhere, maybe that's manually by @maxbrunsfeld?

If we need to store pypi secrets securely in github actions for this repo, it doesn't look like I have sufficient access to do that (and I probably don't have pypi publish access either), so let's wait on Max to weigh in on those.

I will next make a pull request that adds the config I have so far. It builds, but does not publish to pypi yet, although py-tree-sitter-languages does publish wheels to pypi and we could borrow its config.

If my pull request is merged, would you be willing to make a release that only includes that? The current master is somewhat unusable to me (Python segfaults when exiting), and I'd rather not wait until that's fixed.

Regarding embedding languages directly to py-tree-sitter: I see it as a low-priority feature. Currently py-tree-sitter-languages does it pretty well and works with anything that is accessible with import tree_sitter.

any idea why it's segfaulting? can you bisect?

I made a separate issue about the segfaulting.

What is the current process for releasing py-tree-sitter? Just run twine upload -u __token__? Knowing this would help me create something like #117 that fits the existing workflow as well as possible.

Nevermind, I just realized that there is a bash script script/publish that uploads an sdist with twine and a bdist built for whatever system it's running on; this explains why there is only one wheel for Python 3.9 on MacOS.

I currently have a GitHub Actions workflow that uploads wheels to pypi. I will update that into #117 and also make it upload an sdist.

Another option would be to make a workflow that adds wheels to an existing release. Would that be preferable? We could run something like that e.g. on v0.20.0 which is what I currently use.

Closing since wheels are available.