Closed pokey closed 1 year ago
Might be due to changes in the Python tree-sitter API?
Oof,tree-sitter
turned current_field_name
from a method in 0.20.1 into a property in 0.20.2… That’s a major change with a patch version increase.
ha wow that's pretty brutal 😅. Sounds like an easy fix tho?
yeah, but all previous versions of py-tree-sitter-talon would remain broken, so I'd have to find a fix... unfortunately, pypi doesn't let you update version bounds of existing packages :(
Can you use a try catch so that it works with both new and old version?
I could just check the package version. My concern is that past versions of py-tree-sitter-type-provider are irrevocably broken.
There's the possibility of yanking the broken release, but we'll have to see what the tree-sitter developers do.
Cross-linking https://github.com/tree-sitter/py-tree-sitter/issues/152
@pokey With the new release of tree-sitter-type-provider, does this still happen? (You’d have to find a way to update talonfmt’s dependencies, such as reinstalling.)
If this trouble persists, I may have to yank all versions of tstp before the latest one...
If you're following semantic versioning, then I believe all previous versions of tstp will be broken no matter what you do, because you're not allowed to alter previous versions
Is tstp the only library that directly refers to the method that became a property? If so, I would argue to modify the code to use the new property and declare its tree-sitter dependency version to >=0.20.2
I'm switching to exact versions for tree-sitter
rather than ranges, because I don't want to set up tests that test explicitly against versions. I'm also yanking every previous version of tstp. If there's any issues that arise from that, due to unknown downstream dependants, I'll publish a post-release for the yanked version.
Yeah I think exact versions is reasonable for pre-1.0 deps. Annoying that it will cause challenging dependency resolution. I think the best you can do is try to pin to the latest version so if other libraries depend on you, they need to upgrade rather than downgrade to match your deps
This should be fixed now.
We've started seeing errors like the following in pre-commit:
See eg https://github.com/cursorless-dev/cursorless/actions/runs/6109775312/job/16581465472
Seems to happen on all PR branches, and I don't think we've changed anything. Seems like maybe some version bump somewhere. Maybe a Python 3.11 issue?
I haven't done any digging, but figured I'd drop an issue to see if you have idea what might be causing this one