unresolved imports #1085

karrtikr · 2019-05-15T05:50:03Z

@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 :(

The text was updated successfully, but these errors were encountered:

jakebailey · 2019-05-15T16:17:13Z

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 · 2019-05-15T16:59:54Z

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 · 2019-05-15T17:05:43Z

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 · 2019-05-16T03:55:27Z

@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 · 2019-05-16T05:12:41Z

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

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

byteroll · 2019-05-19T13:14:46Z

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 · 2019-05-19T16:02:52Z

works great! thank you!

jakebailey · 2019-06-07T23:31:00Z

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

michaelkolber · 2019-08-12T17:37:35Z

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).

jakebailey · 2019-08-12T17:49:41Z

The problem with scripts is that we have no idea that any one file is going to be run as a script and have its sys.path changed at runtime, and we use the same search paths for all modules. Relative imports are actually the best case scenario, as we can just go relative to the module that includes them.

We consider the workspace root to be the main import root. That mdl module would need to be imported as fldr.pkg.subpkg.mdl in order for us to find it, unless extraPaths or PYTHONPATH are used to tell us additional places to start imports from (i.e. set ["./fldr"] as per the docs). PyCharm has the option of marking directories as "source roots", where they will have imports start from, but cannot be nested. Jedi is very loose and just searches for any module that could possibly be imported in this way (even up and out of the workspace), which can end up finding things correctly, but will mask other issues. See also the comparison done in: #1160 (comment)

There are ongoing issues surrounding this issue, including automatically configuring things as best possible for common structures (like a top level directory used as an import root like src, #1384), allowing multiple names for a single module (#443), fixing nesting (#1360), and others (#1060).

michaelkolber · 2019-08-12T18:32:30Z

Thanks for the detailed write-up, this clarified a lot. Would it be technically feasible to add a workspace-by-workspace option to assume that sys.path has not been changed?

jakebailey · 2019-08-12T18:44:13Z

I guess I'm not sure what you mean; could you provide an example? We already run a script with the selected interpreter to look at sys.path, but past that, it's not examined.

michaelkolber · 2019-08-12T18:56:33Z

Yes, certainly. In the example I gave above, outer1.py runs import pkg.subpkg.mdl. You noted that a script can change sys.path at runtime, which the static analyzer is not capable of picking up on. However, if we assume that sys.path has not been changed, then there should be no error.

Now, we cannot always assume that sys.path hasn't been changed, as it very well can be. But the language server could optionally assume that it has not been changed, rather than assume that it has been changed. This would allow IntelliSense to correctly work even with ambiguous imports, as the user has assured the language server that all modules in the project are not altering sys.path. Did that clarify? Or am I still misunderstanding?

jakebailey · 2019-08-12T19:02:04Z

The language server already assumes that sys.path never changes. It's the change when some file is run as a script that would allow for things to work, which can't yet handle gracefully. The example given is missing a baseline sys.path for the changes you're describing (if that makes any sense). And technically, it's not limited to scripts either; there are other runtime/pwd setups that can make import pkg.subpkg.mdl valid (like people with their code in ./src).

Right now, if you know that fldr is supposed to be an import root, you can tell the LS that by setting "python.autoComplete.extraPaths": ["./fldr"].

trallnag · 2020-03-18T14:22:26Z

Wow, I have spent way too much time on fixing this issue, mark of the brainlet

Ircon · 2020-04-19T16:23:39Z

Is this solution temporary? To add the configuration for every folders is troublesome. And, pylint don't work well. Can fix this problem by other way?

jakebailey · 2020-04-20T00:16:28Z

I don't see this being temporary. Every tool (LS, pylint, pytest, etc) needs to be able to know the valid import roots; no tool knows without configuration how you're going to run the code and has to make some assumption.

If we start adding everything as valid import roots, then our accuracy on resolved imports is poor. It's better to not get some things and require configuration in the exceptional cases than to over-search and end up with silently broken code.

Ircon · 2020-04-20T01:52:50Z

Thank you for your explanation.

brando90 · 2020-06-24T21:30:24Z

Why doesn't vscode use my python path to give intelligent suggestions + show parameters/docs?

https://stackoverflow.com/questions/62564321/how-does-one-have-intellisense-or-intellicode-work-for-my-own-packages-install

#2088

brando90 · 2020-06-25T18:42:26Z

@jakebailey I have an issue where I can go to the declaration of the project in one place but not in the other (and also it never gives me suggestions for project I installed myself with conda develop . or even pip -e .).

What should I do?

e.g.

    import uutils.emailing #1
    from uutils.emailing import send_email, send_email_pdf_figs #2

with 1 I CANNOT go to the declaration with a right click but I CAN with 2 when I go to emailing.

jakebailey · 2020-06-25T18:45:06Z

This is an old closed issue. You have already opened an issue (#2088); there's no need to paste messages in multiple places.

karrtikr mentioned this issue May 15, 2019

unresolved imports microsoft/vscode-python#5544

Closed

This was referenced Jun 7, 2019

Investigate import strictness and editable installs #1169

Closed

Fix editable installs when using extraPaths/PYTHONPATH #1183

Merged

jakebailey closed this as completed in #1183 Jun 7, 2019

jakebailey self-assigned this Jun 7, 2019

jakebailey added this to the June 2019.1 milestone Jun 7, 2019

brando90 mentioned this issue Jun 24, 2020

How to have parameters and docs showing for code installed with codan develop or pip -e . #2088

Open

myialine mentioned this issue Aug 1, 2020

Python unresolved import issue #887

Closed

chrissyast mentioned this issue Feb 4, 2021

Module import error only when debugging microsoft/debugpy#540

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unresolved imports #1085

unresolved imports #1085

karrtikr commented May 15, 2019

jakebailey commented May 15, 2019

tmdag commented May 15, 2019

jakebailey commented May 15, 2019

tmdag commented May 16, 2019 •

edited

Loading

jakebailey commented May 16, 2019

byteroll commented May 19, 2019

tmdag commented May 19, 2019

jakebailey commented Jun 7, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019 •

edited

Loading

trallnag commented Mar 18, 2020

Ircon commented Apr 19, 2020

jakebailey commented Apr 20, 2020

Ircon commented Apr 20, 2020

brando90 commented Jun 24, 2020

brando90 commented Jun 25, 2020

jakebailey commented Jun 25, 2020 •

edited

Loading

unresolved imports #1085

unresolved imports #1085

Comments

karrtikr commented May 15, 2019

Environment data

settings.json

Output

Errors in Developer Tools

jakebailey commented May 15, 2019

tmdag commented May 15, 2019

jakebailey commented May 15, 2019

tmdag commented May 16, 2019 • edited Loading

jakebailey commented May 16, 2019

byteroll commented May 19, 2019

tmdag commented May 19, 2019

jakebailey commented Jun 7, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019

michaelkolber commented Aug 12, 2019

jakebailey commented Aug 12, 2019 • edited Loading

trallnag commented Mar 18, 2020

Ircon commented Apr 19, 2020

jakebailey commented Apr 20, 2020

Ircon commented Apr 20, 2020

brando90 commented Jun 24, 2020

brando90 commented Jun 25, 2020

jakebailey commented Jun 25, 2020 • edited Loading

tmdag commented May 16, 2019 •

edited

Loading

jakebailey commented Aug 12, 2019 •

edited

Loading

jakebailey commented Jun 25, 2020 •

edited

Loading