Pylance-release: Pylance cannot resolve the import of a local .py file

[egeres]

Environment data

Language Server version: 2020.10.2

OS and version: W10 Version 1903

Python version: 3.7.5 64-bit

Expected behaviour

When importing a local python script instead of a module, Pylance should be able to read the methods defined in that file. Or at least recognize the import as something valid.

Actual behaviour

Pylance throws the error Import "my_utils" could not be resolved instead of recognizing the file.

Code Snippet / Additional information

[egeres]

Apparently Pylance does read local Python files. My issue comes from the structure of the project being as follows:

root/
    folder_0/
        main.py
        my_utils.py

Pylance reads the script when it's placed under the root folder, instead of folder_0. However, if my_utils.py is placed in that location, running main.py with the path as follows: D:/folders/root/ gives an error. The error does not occur when both main.py and my_utils.py are under the same subfolder.

Maybe Pylance should be able to recognize an import of a local file from a subfolder, instead of this file needing to exist in the root of the project ?

[jakebailey]

See the troubleshooting doc: https://github.com/microsoft/pylance-release/blob/master/TROUBLESHOOTING.md#unresolved-import-warnings

You can choose the import roots with extraPaths, open the subfolder, or use a multi-root workspace to split out the roots.

Also related is #253.

[Promethian3]

I'm actually having the same issue;
pylance recognizes a local .py file if I import something or everything from it (using relative import), but it doesn't recognize the file when I do a simple import.

---

EDIT:

I followed @jakebailey 's link and followed through the instructions, solving the issue.
Thanks!

[geekgao]

Too much troubles.
I think there must be a better solution like before.

[AndreasLuckert]

I'm still having this error, so I filed a question on StackOverflow. Thanks in advance for your consideration.

[jakebailey]

I believe you filed #724 for your specific issue.

As far as I can tell, the issues in this thread were solved by setting extraPaths. See also #253 for general issues importing things from scripts (where import roots may differ). I'm going to close this to avoid this issue becoming a catch-all for instances where imports cannot be resolved (which makes giving solutions or finding bugs very difficult).

[cesarvargas00]

I'm actually having the same issue;
pylance recognizes a local .py file if I import something or everything from it (using relative import), but it doesn't recognize the file when I do a simple import.

EDIT:

I followed @jakebailey 's link and followed through the instructions, solving the issue.
Thanks!

I think that relative imports should be the way to go, in this case. Is there a good case where importing without the .(dot) would be a good practice?

[jakebailey]

The whole "relative" versus "absolute" is a big style war in Python, I think.

If you're looking for distinguishers besides "it works", relative makes it easier to refer to things with long names or unclear roots, but absolute means you can move files without having to update everything. I'm sure there are other reasons I'm missing.

[ror3d]

If the "relative" import is the preferred way for the linter, then it should tell you that as an option to resolve the issue. Adding the "python.analysis.useImportHeuristic": true that's mentioned in #253 solved the warnings for me, but apparently this is a hidden setting so that's not really that helpful.

[jakebailey]

Pylance isn't a linter and isn't in the business of preferring one style of import over another or suggesting you use a particular style.

Relative imports are just easier to resolve, as they require no context except the location of the current file. Absolute imports require knowing where the code is run (how imports are rooted), hence extraPaths.

The heuristic is an experiment we're making to try and help fix cases where users haven't set extraPaths, but expect imports to resolve. It's not intended to be exposed until we're confident in the method and have a chance to figure out how it's going to look when finalized.