Update to Jedi 0.17 #11252
Update to Jedi 0.17 #11252
Conversation
lf chosen to match package{,-lock}.json
This includes updating to the latest parso too.
davidhalter/jedi#1548 is actually fixed upstream, but as-yet unreleased.
|
Kudos, SonarCloud Quality Gate passed!
|
Codecov Report
@@ Coverage Diff @@
## master #11252 +/- ##
=======================================
Coverage 61.08% 61.08%
=======================================
Files 601 601
Lines 33085 33085
Branches 4671 4671
=======================================
Hits 20209 20209
Misses 11858 11858
Partials 1018 1018 Continue to review full report at Codecov.
|
| @@ -596,6 +596,7 @@ def _process_request(self, request): | |||
| line=request["line"] + 1, | |||
| column=request["column"], | |||
| path=request.get("path", ""), | |||
| project=jedi.get_default_project(os.path.dirname(path)), | |||
There was a problem hiding this comment.
Thanks for the PR! Btw What upstream issue is this for?
There was a problem hiding this comment.
Jedi 0.17.0 introduced project support, so the signature for jedi.Script changed.
There was a problem hiding this comment.
This is true, however this specific change is to work around davidhalter/jedi#1548, which is fixed but not yet released. There miiight be some benefit to removing this line when the fix is released (so people can continue to use 0.16 if they really need to for some reason), but as @kimadeline mentions, projects are the direction that Jedi is going.
Ideally I think we'd pass in the actual project root (which VSCode knows) rather than getting jedi to guess it, however I couldn't immediately see that in the available data. This spelling keeps the existing behaviour, though we may be able to do better in the future.
For #11221
package-lock.jsonhas been regenerated by runningnpm install(if dependencies have changed).Light testing locally suggests that this works for simple cases, but I've not done any in-depth testing.
PR partly to get an initial CI run against the updated Jedi.