Unresolved import problem for files in sub-directories in a workspace

[OllieKampo]

Its hard for me to explain my exact issue because I don't know all the correct terminology.
Basically if I try to import one of my own python files into another of my own python files whilst both are in the same "sub-directory" of my "main" workspace directory then I get an unresolved import problem unless I put the full file path from the "main" directory into the import in which case the python files no longer run.
Please see my example below.

Say I have files setup like this: (I've obviously omitted folders and files you don't need to see)

C:.
│   Potassco.code-workspace
│
├───.vscode
│       settings.json
│
└───Work
    └───Hospitality_Domain
        └───Version_7
            │   Architecture.lp
            │   domain_setup.lp
            │   Parser.py
            │   Robot_Hotel.sp
            │   Simulate.py
            │   SPARC.jar
            │
            └───__pycache__
                    Parser.cpython-36.pyc

If I try to import Parser.py into Simulate.py as such:
import Parser
I get the unresolved import problem but the code runs just fine (as we would expect).

However if I instead put this:
import Work.Hospitality_Domain.Version_7.Parser
I do not get the unresolved import but the code does not run, (which is also what I would expect).

I'm guessing my problem is probably something simple, can anyone help?

[chudytom]

I get the unresolved import problem but the code runs just fine (as we would expect).

However if I instead put this:
import Work.Hospitality_Domain.Version_7.Parser
I do not get the unresolved import but the code does not run, (which is also what I would expect).

I'm guessing my problem is probably something simple, can anyone help?

I have the very same problem. There is always either en error on the IntelliSense part or while running the code.

[jakebailey]

The language server uses the root directory (given by VSC) as the base of the imports. If you want to change that, you can try modifying your VS Code config for the workspace to point to that directory, like:

"python.autoComplete.extraPaths": ["./Work/Hospitality_Domain/Version_7"]

Though it might be better to just open that folder (Version_7) when you want to work on that specific project, rather than opening the entire C: drive in VSC, which I think has some bad implications due to file watches, workspace indexing on the entire drive, etc.

When running a file as a script, the Python interpreter does some extra stuff, I believe adding the script's directory to sys.path. The LS doesn't necessarily know that any given file is going to be run as a script or not, so doesn't know about import paths which rely on that behavior.

[xobs]

I'm having the exact same issue.

I have a .env file that contains PYTHONPATH that points to those directories, however the python language server appears to be ignoring that file. The language server doesn't work unless I set python.autoComplete.extraPaths.

The Python Language Server should honor python.envFile and the PYTHONPATH variable contained there, and add those values to its search path.

[xobs]

It should be noted that the python.autoComplete.extraPaths workaround only works if the .py file in question is in the root of the workspace. If the .py file is not in the root of the workspace, then python.autoComplete.extraPaths does not fix the issue.

The workaround is to only use vscode from a directory where the .py file is at the root of the workspace.

For example, in my project, I have my hardware definition file in an hw/ directory, and my dependencies are under hw/deps/. I cannot run vscode from /, I must run it from /hw/. Otherwise, it will not find any dependencies.

[chudytom]

I tried your solution but it doesn't work in my case. Maybe just because I'm using my custom module for it. Since it looks like a different scenario I described everything in another issue:
microsoft/vscode-python#5786
Please look at it, maybe you will have an idea how to fix it.

[OllieKampo]

@MikhailArkhipov I am not sure whether I am using an editable install?
I do not even know what that means, how do I check this?
Is it referring to an editable install of VScode or Python or what?

[OllieKampo]

I have been trying to enable Jedi to fix the problem.
I have installed Jedi in my conda virtual environment and put the correct path into VScode.
However it does not work at all, literally does nothing, can someone point me to a tutorial or something?
I am beyond confused at this point :(

[jakebailey]

The python extension controls this; you shouldn't need to install jedi yourself. Set "python.jediEnabled": true, or remove the false from your config (as true is the default).

[jakebailey]

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

@OllieKampo Did that configuration option work? Have you tried choosing a different directory to open (that isn't the C drive)? Happy to repopen if you're still having an issue with the configuration updated and in LS v0.3.1+.

[OllieKampo]

@jakebailey I'm not sure what I did exactly to fix it, but I followed your advice and made a new directory for my workspace that is less "deep", it only has one level of directories inside the root directory for the workspace.

This seems to have somehow fixed it now without having to change the configuration options at all.
It is working perfectly now, all imports are correct and the server seems to have full functionality, if there is any information you want about my setup I'll be happy to send it across.

I think I may have an idea what the problem was though, my old workspace was on a onedrive synced desktop, so although I thought I was opening "C:\Users\OllieKampo\Desktop..." I was actually opening "C:\Users\OllieKampo\OneDrive\Desktop...".
I think possibly this was causing the error but I am not sure.

Thanks for your help an efforts in this matter though, its really appreciated :)
Apologies for my lack of knowledge of the technical wording of things also.

[xobs]

It doesn't seem very reliable. I have the path defined both in PYTHONPATH in .env and in settings.json, and all of the repositories work except the one with an underscore.

Is there something special about python paths with an underscore?

{
    "python.autoComplete.extraPaths": [
        "deps/litescope",
        "deps/litex",
        "deps/litex_boards",
        "deps/lxsocsupport",
        "deps/migen",
        "deps/valentyusb"
    ]
}

Gives me unresolved import 'litex_boards.partner.platforms.fomu_evt' Python(unresolved-import) even though python3.exe is able to see it just fine. All other deps work just fine.

[jakebailey]

It sounds like you should be setting "./deps" as the path, not each individual directory, unless I'm mistaken about the contents of those directories. I.e., from a glance my impression would be that the import litex_boards.partner.platforms could be deps/litex_boards/partner/platforms, not deps/litex_boards/litex_boards/partner/platforms (note the extra directory). Imports are rooted from the list that you provide.

[jakebailey]

You shouldn't mix both extraPaths and PYTHONPATH (although we have some code in place to prevent duplicates, so it's probably not causing any issues at the moment).

[xobs]

The file that it's trying to import is, in fact, .\deps\litex_boards\litex_boards\partner\platforms\fomu_evt.py. I switched to using python.autocomplete.extraPaths because PYTHONPATH wasn't working.

[jakebailey]

Huh, alright. My assumption was wrong. 🙂

To confirm, are you using the daily build? Or are you still on stable? Daily contains a few fixes to the search path code that stable doesn't yet have.

I'd appreciate it if you could open a new issue with trace logging enabled (and hopefully a code sample). Mainly, I'd like to see the search paths printed at the start. https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#filing-an-issue

[xobs]

I've removed python.autocomplete.extraPaths and started relying solely on PYTHONPATH. This does work now, in that it's able to find all of the rest of the packages. However, litex_boards still gives "Unresolved import".

I see the same behavior if I remove the .env file and rely on python.autocomplete.extraPaths.

[jakebailey]

I see the same behavior if I remove the .env file and rely on python.autocomplete.extraPaths.

Yes, the extension concatenates those two lists before sending them to us, so they are identical from our point of view (but setting PYTHONPATH has a much stronger execution-time impact, because Python itself reads that variable, hence why it's not the first thing we recommend).

[xobs]

I'm now running the daily build. I've submitted a new issue at #1223 (comment)