unresolved imports

[karrtikr]

@tmdag commented on Thu May 02 2019

Everything was just working fine. I wanted to give it a try to suggested 'Visual Studio IntelliCode 1.1.5'. I've installed it and got some popup that I didn't read carefully, that it has to connect to Microsoft server or something, I clicked OK.
From this moment my existing python and pyqt projects are screaming with errors 'unresolved import' for local files like QtUI or anything else for that matter. Uninstalling or disabling IntelliCode did not help.

Environment data

• VS Code version: 1.33.1
• Extension version (available under the Extensions sidebar): 2019.4.2 (30 April 2019)
• OS and version: 5.0.7-200.fc29.x86_64
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.3
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
• Relevant/affected Python packages and their versions: Visual Studio IntelliCode 1.1.5

---

@karrtikr commented on Thu May 02 2019

Please provide answer to the following questions,

• Please inform if you are using Language server or jedi, i.e check the value of python.jediEnabled in settings.json, if any such setting.
  Clicking OK enables Language server (python.jediEnabled: false), which might be your problem. To rectify that just change it to true or remove that setting.

• Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

• Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)

---

@tmdag commented on Fri May 03 2019

Enabling python.Jedi fixed the issue. That also brought back the popup

settings.json

"python.jediEnabled": false,

Output

Starting Microsoft Python language server.
[Info  - 7:51:57 AM] GetCurrentSearchPaths /usr/bin/python3 
[Info  - 7:51:57 AM] Python search paths:
[Info  - 7:51:57 AM]     /usr/lib64/python3.7
[Info  - 7:51:57 AM]     /usr/lib64/python3.7/lib-dynload
[Info  - 7:51:57 AM]     /usr/local/lib64/python3.7/site-packages
[Info  - 7:51:57 AM]     /usr/local/lib/python3.7/site-packages
[Info  - 7:51:57 AM]     /usr/lib64/python3.7/site-packages
[Info  - 7:51:57 AM]     /usr/lib/python3.7/site-packages
[Info  - 7:51:57 AM] Configuration search paths:
[Info  - 7:51:59 AM] Microsoft Python Language Server version 0.2.66.0
[Info  - 7:51:59 AM] Initializing for /usr/bin/python3

Errors in Developer Tools

console.ts:134 [Extension Host] Python Extension: Failed to discover if linter pylint is available, Class name = f, Arg 1: {"configService":{"serviceContainer":{"container":{"options":{"autoBindInjectable":false,"defaultScope":"Transient"},"guid":"97b73b07-0c24-218d-41a4-266530363ffe","_bindingDictionary":{"_map":{}},"_snapshots":[],"_middleware":null,"parent":null,"_metadataReader":{}}},"workspaceService":{}},"_product":3,"_id":"pylint","_configFileNames":[".pylintrc","pylintrc"],"workspaceService":{}}, Arg 2: <Uri:extension-output-#3>, Return Value: undefined TypeError: Cannot read property 'uri' of undefined
	at f.isLinterAvailable (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:678059)
	at f.module.exports.o.value (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:1:17815)
	at f.promptIfLinterAvailable (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:677148)
	at S.enableUnconfiguredLinters (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:682168)
	at S.getActiveLinters (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:680590)
	at S.isLintingEnabled (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:680390)
	at w.shouldLintDocument (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:696472)
	at w.lintDocument (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:694573)
	at module.exports.t.LinterProvider.onDocumentOpened (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:704064)
	at Array.module.exports.t.LinterProvider.constructor.documents.onDidOpenTextDocument.e (/home/myuser/.vscode/extensions/ms-python.python-2019.4.12954/out/client/extension.js:83:703191)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:728)
	at define.constructor._toDispose._documentsAndEditors.onDidAddDocuments.e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:517:782)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:708)
	at u.$acceptDocumentsAndEditorsDelta (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:521:981)
	at d._doInvokeHandler (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:622:11)
	at d._invokeHandler (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:621:716)
	at d._receiveRequest (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:620:394)
	at d._receiveOneMessage (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:619:141)
	at define.constructor._protocol.onMessage.e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:617:400)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:708)
	at e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:40:460)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:708)
	at a (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:172:467)
	at e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:172:513)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:708)
	at y._receiveMessage (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:181:276)
	at define.constructor._socketDisposables.push._socketReader.onMessage.e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:178:415)
	at u.fire (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:44:708)
	at f.acceptChunk (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:175:35)
	at define.constructor._register._socket.onData.e (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:174:410)
	at Socket.t (/usr/share/code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:182:689)
	at Socket.emit (events.js:182:13)
	at addChunk (_stream_readable.js:279:12)
	at readableAddChunk (_stream_readable.js:264:11)
	at Socket.Readable.push (_stream_readable.js:219:10)
	at Pipe.onread (net.js:636:20)

console.ts:134 [Extension Host] Python Extension: Python Extension (Error in Failed to check if file needs to be fixed, method:doesFileNeedToBeFixed): Error: ENOENT: no such file or directory, open '/home/myuser/dev/mycode/.vscode/settings.json'

---

@Ronkiro commented on Fri May 03 2019

An addition.

I also had the same problem (Windows 10 Enterprise), fully reinstalling VSCode (Uninstalling and removing the folders from APPDATA, user, etc) solved the issue. Had a lot of problems with language server too, they all seem solved after that.

Maybe it's a config problem, or something related to PATH.

---

@karrtikr commented on Tue May 14 2019

Closing as the issue seems to be solved. Please open up a fresh issue if the problem re-occurs.

---

@tmdag commented on Tue May 14 2019

@karrtikr,well not really, unless "Microsoft Python language server" is NOT meant to be used ??

If that is the case, can I get rid of that annoying popup that asks me to turn int back on ?

don't see really any solution, only work around which i don't think it is a solution at all :(

[jakebailey]

Judging by the screenshot, this looks like a case of an import that is not rooted at the workspace root. If you have a path like foo/bar/baz starting at the workspace root, you must import it as foo.bar.baz (or similar). If you're trying to just do import baz, then you're going to have to either open the other folder, or modify .env's PYTHONPATH or settings.json's extraPaths to specify the extra root (for example, ["./foo/bar"]).

[tmdag]

thanks @jakebailey !
as you can see in the screnshot, module i am importing is in a root of main python script. Python itself works 100% fine, no issues at all but I am still getting an error with unresolved issues.
Enabling python.Jedi fixed it.

So just to understand - In order to use "Microsoft Python language server" instead of python.Jedi, I would have to redesign every python script ?

[jakebailey]

That's not what I'm saying, no. I'm saying that we consider the "root" to be what VSC gives, which is the directory you have open. From what I can see in the screenshot (which is cut off, so I can't give you any specific help), preferences.py is not at the root of the workspace, so we can't consider import preferences to pick up that file; we can't tell the context in which you're going to run the script (or even that some specific file is supposed to be a script and would be subject to extra sys.path magic when executed). You can modify your configuration to give the LS the info it needs to know how to interpret the imports and make those messages go away (and get correct completion).

[tmdag]

@jakebailey Thanks for your time and explanation. Maybe it's the problem of my workflow then.
Currently my workspace is designed like so:

WORKSPACE
testproject (imported directory)
├── .git
└── projectmain
       └── myproject.py
       └── mymodule.py

So I guess "module01.py" is not at the "root" of workspace but it is at the root of mainprojectfile.py, hence python works by just 'import module01'

Scenario02: If I import 'projectmain' directly, instead of 'testproject' to the Workspace - it does work fine (but i will "loose" top level elements, including my .git)

WORKSPACE
projectmain (imported directory)
├── myproject.py
└── mymodule.py

Scenario03: If I would keep my original folder structure and do
from projectmain import mymodule
I won't get linting errors!, but Python script will not work...
ModuleNotFoundError: No module named 'projectmain'

Scenario04: adding path to python - this would also not work for linter:

import sys
sys.path.insert(0, "/home/user/testProject/projectmain")
import mymodule
mymodule.testme()

So.. either I would have to redesign my workflow or modify PYTHONPATH (or settings) for every project.
Or enabling python.Jedi while keeping my current structure, and figure out how to get rid of popup asking for LS.

[jakebailey]

You can set per-workspace VSC settings. Try .vscode/settings.json in the folder you have opened with:

{
	"python.autoComplete.extraPaths": ["./projectmain"]
}

[byteroll]

You can set per-workspace VSC settings. Try .vscode/settings.json in the folder you have opened with:

{
	"python.autoComplete.extraPaths": ["./projectmain"]
}

Thank you, it works.

[tmdag]

works great! thank you!

[jakebailey]

This is now documented here: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#unresolved-import-warnings

[michaelkolber]

That's not what I'm saying, no. I'm saying that we consider the "root" to be what VSC gives, which is the directory you have open. From what I can see in the screenshot (which is cut off, so I can't give you any specific help), preferences.py is not at the root of the workspace, so we can't consider import preferences to pick up that file; we can't tell the context in which you're going to run the script (or even that some specific file is supposed to be a script and would be subject to extra sys.path magic when executed). You can modify your configuration to give the LS the info it needs to know how to interpret the imports and make those messages go away (and get correct completion).

@jakebailey Forgive my confusion, but why is this an issue with absolute imports? Although I understand why relative imports might pose a problem (since it's possible to run into a relative import beyond the top-level package), aren't absolute imports the same regardless of where the calling script is started from?

If I have

dir  # VS Code is open here
 |
 +-- fldr
 |    |
 |    +-- pkg
 |    |    |
 |    |    +-- subpkg
 |    |          | 
 |    |          +-- mdl.py
 |    |
 |    +-- outer1.py
 |
 +-- outer2.py

then if outer1.py runs import pkg.subpkg.mdl, then it will work, whether it's run directly, whether outer1 is imported from the REPL, or whether it's imported in outer2.py. I don't understand where the ambiguity is in absolute imports (nor, besides edge cases, relative imports).