-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure GitHub Actions to build binary wheels and upload to pypi #117
Conversation
I'd love to have this as well, I'm working on a project that uses tree-sitter, and some users have had problem building tree-sitter. Is there anything I can do to help? |
For now, you can use https://github.com/Akuli/py-tree-sitter-builds which installs |
This awesome! I can add PyPi credentials to the org if they are needed for publishing. When you get a chance, could you write up what you think still needs to be done? |
I think a good next step would be including wheels for the
To get this working:
|
You can certainly ship a wheel that has both MIT and Apache 2.0 code in it, just need to make sure all of the license files are present with correct attribution. |
Personally, I think just doing it based on any tag that starts with
I can take care of that.
I'm not familiar with cibuildwheel, maybe @lunixbochs can advise on that issue.
Maybe we just test by creating a tag with a qualifier like |
Ok, the |
This is more of a thing with the tests than with cibuildwheel. The tests use A few ways how I could work around it, not sure yet which I will choose:
|
You can just use GH upload action, and manually point pip to the locally downloaded wheels (or even download the wheel in another action). |
tests/test_tree_sitter.py
Outdated
LIB_PATH = path.join(project_root, "build", "languages.so") | ||
if os.getenv("PY_TREE_SITTER_TESTS_FORCE_REBUILD_LANGUAGES"): | ||
try: | ||
os.remove(LIB_PATH) | ||
except FileNotFoundError: | ||
pass | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth it to have a .so name that contain the python version/platform in the same way that pyc files ends with for example cpython-310
? That would avoid any conflicts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually has to be something like cpython-310-amd64
, because 32-bit and 64-bit wheels are built in the same environment. I'll change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, and like also sys.platform to be sure ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out that just placing the languages binary to current working directory works. This seems to be how cibuildwheel is meant to be used: it makes a new working directory for each wheel build just so that you can make a mess in it to be cleaned up before the next build.
It is working: https://test.pypi.org/project/tree-sitter-test/ |
Working for me on mac M1 and Linux x86_64 for Python 3.10. $ pip install tree-sitter-test --extra-index-url https://test.pypi.org/simple If there are lurkers that don't know how to point pip at test-pypi |
Ready for review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just left one minor question.
Would absolutely love to see this merged soon. It looks like it is ready to be merged? EDIT: I have now been able to deploy a python app using tree-sitter-test from @Akuli's repository, whereas I had not been able to compile this repo's source on my docker image. |
Discussed on #103.
Still needs more work.