Jedi 0.12

[MikhailArkhipov]

Fixes #1400
Fixes #1033

This pull request:

• Has a title summarizes what is changing
• Includes a news entry file (remember to thank yourself!)
• Has unit tests & code coverage is not adversely affected (within reason)
• Works on all actively maintained versions of Python (e.g. Python 2.7 & the latest Python 3 release)
• Works on Windows 10, macOS, and Linux (e.g. considered file system case-sensitivity)

[davidhalter]

The diff of this PR is quite hard to view, so I'm not 100% sure what you changed. Just one small note: Remember that if you want good virtualenv support you probably have to write a bit of logic to let jedi scan folders for environments (and let users choose).

[brettcannon]

@davidhalter I think https://github.com/Microsoft/vscode-python/pull/1418/files#diff-7d38e4fd5066eabf8a4ae3890e028f29 is the only change we made to our code and the Jedi/parso code is straight from the tarballs. Did something specific change in 0.12 in regards to virtualenv support?

[davidhalter]

It fundamentally changed. Previously virtualenvs were not really supported. In some cases the sys path was changed by a bit in these earlier versions.

Now you can actually choose which environment (Python 2.7, 3.3, 3.4, 3.5... or virtualenv) you want to use for static analysis. Jedi then runs a subprocess in that environment to check for the sys path and other important stuff. However if jedi users don't provide an environment (there's also search functions provided by jedi) you cannot really gain from that and apart from a few minor improvement the feature doesn't help you.

[brettcannon]

@davidhalter thanks for the info! I opened #1445 to track this.

[DonJayamanne]

@davidhalter

However if jedi users don't provide an environment (there's also search functions provided by jedi) you cannot really gain from that and apart from a few minor improvement the feature doesn't help you.

Today when users switch between different Python environments, we re-launch Jedi within that particular python environment. Hence I do not see the need to provide the environment info to the Jedi api.

[davidhalter]

@DonJayamanne Yeah, that might work as well. It's pretty similar. It's just that in jedi this complexity exists anyway (for other IDEs/Editors) and you could probably get rid of some code. Makes it way easier.

IMO it's also not necessary anymore to use a subprocess for Python (to protect against segfaults etc), because that's already done by Jedi itself now.