Sublime Forum

Migrate sublime-tree-sitter to tree-sitter-language-pack

#1

Grant Jenks’ “tree-sitter-languages” package (aka grantjenks/py-tree-sitter-languages) is no longer maintained. The replacement, tree-sitter-language-pack (aka goldziher/tree-sitter-language-pack) is maintained and supported.

If whomever maintains sublime-tree-sitter plugin wants to keep taking advantage of updated pre-built wheels for treesitter languages, the plugin really needs to migrate to using tree-sitter-language-pack instead of tree-sitter-languages. Their APIs are nigh-identical, porting should be fairly simple.

I spent a brief period looking at what all would be needed, and it didn’t seem like it would require a huge amt of work (mostly just updating the much larger list of pre-built parsers/grammers in the replacement vs the original). Alas I didn’t have time to attempt an actual migration and test.

I can certainly fork and attempt the migration on my fork, but don’t want to do so if someone else is already working on the same migration. If anyone else already is, can they please let me know? Happy to help work with whomever started working on it, as well.

Thanks!

0 Likes
#2

Okay, so guess I’m at least trying to do this, until I hear otherwise or run out of time/resources. Please still reach out if you’re already working on it, I’ve begun a dialog with the treesitter-language-packs folks for an iterable API, and just need to figure out the best way to wire everything together (with minimal bubblegum & bailing wire ideally, more structural duct tape).

0 Likes
#3

Just do it. We appreciate.

0 Likes
#4

Anyone really using this package?

0 Likes
#5

Slight problem: tree-sitter-language-pack says it requires Py 3.9.x.

I’m investigating why it says that (unclear if tied to binary interfaces somehow, or just because that’s what the dev had at the time). Alas, that might also create some compat problems with the bound wheels if I try to relabel it as 3.8-compatible even if the Py components are fine with 3.8.

Will update once I have a better handle on it. Worst-yet-salvagable case, presuming there isn’t a binary blocker reason, I can just rebuild the .so’s for binding against 3.8 as well. Or, it could turn into a motivation- and time-eating singularity I might have to put out of my misery. We’ll see.

0 Likes
#6

Okay, so answer is problematic on all fronts. They’re using 3.9 for typing, so getting a 3.8-compat version would require a separate fork, yadda yadda yadda…not happening, esp. with the recent guidance around ST’s internal Py changes coming which basically solve this issue from the ST side.

Will revisit after ST has moved to something more modern than 3.8. I’m a little unclear how soon “dev” versions will be available to customers with the more recent Py system, would appreciate any info there. I’ll do the changes (they’re actually mostly done), just waiting for a ST with Py >3.8 to test.

I’m presuming that sublime-tree-sitter will have to step forward too, due to tree-sitter itself already requiring >3.9, so there’s a dependency on that as well for release, but I can dev/test with current pkg given ST with Py > 3.9.

0 Likes