Jedi does not use current interpreter

[emonette123]

Environment data

Version: 1.30.2 (user setup)
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:54:13.295Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Windows_NT x64 10.0.16299

Name: Python
Id: ms-python.python
Description: Linting, Debugging (multi-threaded, remote), Intellisense, code formatting, refactoring, unit tests, snippets, and more.
Version: 2019.1.0
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-python.python

Expected behaviour

VS Code uses the current interpreter to run jedi.

Actual behaviour

VS Code uses one of the installed interpreter on the computer. Seems to favor the latest versions of python installed.

Steps to reproduce:

1. Run VS Code with setting "python.pythonPath" pointing to a Python environment not installed on Windows. The environment is working, but it is not in the Windows Registry. Use python 3.4.x.
2. Let VS Code discover tests, it will work properly, but the Codelens will not appear.
3. Check the Developer Tools log:

jediProxy, Error (stderr)     import _socket
ImportError: Module use of python34.dll conflicts with this version of Python.
.
.
.
jedi.api.exceptions.InternalError: The subprocess C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\python.exe has crashed.

For some not in my control reasons, I have to configure my environment to have the python distribution dll directory in the PYTHONPATH. This prevents python 3.6 to work properly since the _ctypes.pyd, _socket.pyd and friends found will be the ones for python 3.4.

My current interpreter is set to python 3.4.5 and is located on my D: drive. Why is VS Code using an interpreter located on the C: drive and of version 3.6.x to run jedi? I guess if I had no other interpreter installed, it would work properly. But I cannot test that since I do not have the rights to remove those installed interpreters on my C: drive.

[emonette123]

I confirm that not having any standard installation of python (by standard, I mean it is in the registry and/or on the root of the C: drive) fixes that issue. The problem with having Jedi running on a different python interpreter breaks the CodeLens for tests... I now have CodeLens working with my custom Python 3.4.5 distribution. When a python 3.6 standard distribution was available, CodeLens would not show up, because of Jedi failing.

[emonette123]

Another workaround is to set the VIRTUAL_ENV environment variable, this makes Jedi being used with the virtual environment instead of the default one, inferred from whatever distribution you have on your PC.