Looks like Microsoft.PythonTools.Analyzer.exe ignores Python Environment IDE settings and uses
python.exe -S -E -c "import sys;print('\n'.join(sys.path));print('-');import site;site.main();print('\n'.join(sys.path))"
to detect libraries locations.
Yes, we found that it was more reliable to query the Python interpreter for where its libraries are rather than relying on a single user-provided path. (For example, PyPy has multiple standard library folders, and this is the best way to handle it.)
If you specify search paths in the project, those are handled within VS and not by this process.
What exactly is not working?
Microsoft.PythonTools.Analyzer.exe can not scan paths returned by MSys2/Python
/usr/lib/python34.zip
/usr/lib/python3.4/
/usr/lib/python3.4/plat-msys
/usr/lib/python3.4/lib-dynload
-
/c/Users/User
/usr/lib/python34.zip
/usr/lib/python3.4
/usr/lib/python3.4/plat-msys
/usr/lib/python3.4/lib-dynload
/usr/lib/python3.4/site-packages
Ah, that's a good point.
Does MSys2/Python have any way to format paths in correct style for Windows? (Do those paths even have a proper Windows equivalent? It's been so long since I used MSys2...)
When running MSys2/Python
sys.platform is equal to msyssys.executable is equal to /usr/bin/pythoncygpath -m /usr/bin/python returns the Windows path, i.e. C:/Msys2/usr/bin/python, for instance (MSys2 path control).So we probably need to change that short command into a more significant script that can do some proper handling of non-Windows-like platforms. It seems like something that may be interesting anyway - there's been some thought given to handling remote environments that would also need this.