Set ABI 14 for pypi builds #11
Conversation
On publish, the pypi workflow currently regenerates our parser for ABI 15 because that's the default from the central workflow [1]. In Python, one needs py-tree-sitter [2] to load the robot language. Since py-tree-sitter folks have not yet finished ABI 15 migration [3], there's currently no way to load our binding. Using the lattest py-tree-sitter 0.24 would fail with "ValueError: Incompatible Language version 15. Must be between 13 and 14". Therefore to make tree-sitter-robot available for users, we enforce ABI 14 on regeneration for upload. PS: Some of the central language bindings have basically the same problem. However, since they have published former pypi releases with lower ABI versions, there's something users can fallback to. We don't have previous releases, so no fallback is available. [1] https://github.com/tree-sitter/workflows/blob/ec44bc4f4667a458dd397ed9864f1b560e8fdca2/.github/workflows/package-pypi.yml#L24 [2] https://github.com/tree-sitter/py-tree-sitter [3] tree-sitter/py-tree-sitter#333
Currently there's a minor mismatch. The git repository is tagged for 1.1.0, but package configs say 1.0.0. Fix for upcoming release.
@Hubro Sorry for the reiteration, I've overlooked that. Hope the code change does what it shall, don't know how I could test publish related things. And thanks a lot for caring about the previous PR so fast 🙌 |
|
@haxtibal How are you changing the version string in all these places? Is there a handy shortcut or are you doing it manually? EDIT: Since you missed the version string in package.json (which I had set to "1.1.0"), I'll assume you used good-old find and replace 😁
Most of the contribution I've received on my repos are requests for features or bug reports, so receiving such high effort and quality contribution is a real thrill! 😁 I'm used to seeing commit messages like "fix" and "WIP", so reviewing your PR yesterday was straight up trippy. |
|
Thanks again! 🚀 |
Yes, I know no other way, but I'm also quite new to tree-sitter. One could call
Hm, sadly it didn't help.
EDIT 1: However, pip install will fetch the wheel instead of the sdist if there's a suitable wheel. Our wheels are seemingly not just built from the sdist, but once again regenerate the parser, now with ABI 15. Don't know if this is works as designed, or a bug in the central actions, or wrong application of the actions... will investigate further. Let's see what tree-sitter folks say about it, see tree-sitter/workflows/pull/28. |
|
@Hubro With the fix now merged at tree-sitter side, would you mind making another release? Guess the most straight thing would be to tag a 1.1.2 without any source changes. Sorry again ¯_(ツ)_/¯ |
|
Good to hear it wasn't my fault! 😁 New release triggered! |
Now it failed because git tag was 1.1.2, but package versions in pyproject.toml, package.json, etc. were still 1.1.1, which causes upload error since we can't overwrite existing versions. "without any source changes" was a bad advice... One more try? What could possibly go wrong 😁 (I'd probably try to delete the 1.1.2 tag, change the package files to 1.1.2 and then tag again as 1.1.2 - but please decide on your own) |
On publish, the pypi workflow currently regenerates our parser for ABI 15 because that's the default from the central workflow.
In Python, one needs py-tree-sitter to load the robot language. Since py-tree-sitter folks have not yet finished ABI 15 migration (tree-sitter/py-tree-sitter#333), there's currently no way to load our binding. Using the lattest py-tree-sitter 0.24 would fail with "ValueError: Incompatible Language version 15. Must be between 13 and 14".
Therefore to make tree-sitter-robot available for users, we enforce ABI 14 on regeneration for upload.
Also prepare package configs for upcoming tag version.
PS: Some of the central language bindings have basically the same problem. However, since they have published former pypi releases with lower ABI versions, there's something users can fallback to. We don't have previous releases, so no fallback is available.