Repository navigation
Unresolved import problem for files in sub-directories in a workspace #1099
Description
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?
Activity
[-]Unresolved import problem for files in sub-directories in a work space[/-][+]Unresolved import problem for files in sub-directories in a workspace[/+]chudytom commentedon May 18, 2019
I have the very same problem. There is always either en error on the IntelliSense part or while running the code.
jakebailey commentedon May 18, 2019
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:
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 commentedon May 22, 2019
I'm having the exact same issue.
I have a
.envfile that containsPYTHONPATHthat points to those directories, however the python language server appears to be ignoring that file. The language server doesn't work unless I setpython.autoComplete.extraPaths.The Python Language Server should honor
python.envFileand thePYTHONPATHvariable contained there, and add those values to its search path.xobs commentedon May 22, 2019
It should be noted that the
python.autoComplete.extraPathsworkaround only works if the.pyfile in question is in the root of the workspace. If the.pyfile is not in the root of the workspace, thenpython.autoComplete.extraPathsdoes not fix the issue.The workaround is to only use vscode from a directory where the
.pyfile 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 underhw/deps/. I cannot run vscode from/, I must run it from/hw/. Otherwise, it will not find any dependencies.chudytom commentedon May 26, 2019
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 commentedon Jun 4, 2019
Mikhail Arkhipov (@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 commentedon Jun 4, 2019
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 commentedon Jun 4, 2019
The python extension controls this; you shouldn't need to install jedi yourself. Set
"python.jediEnabled": true, or remove thefalsefrom your config (as true is the default).jakebailey commentedon Jun 7, 2019
This is now documented here: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#unresolved-import-warnings
Oliver Michael Kamperis (@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 commentedon Jun 8, 2019
Jake Bailey (@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 commentedon Jun 19, 2019
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 commentedon Jun 19, 2019
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 importlitex_boards.partner.platformscould bedeps/litex_boards/partner/platforms, notdeps/litex_boards/litex_boards/partner/platforms(note the extra directory). Imports are rooted from the list that you provide.jakebailey commentedon Jun 19, 2019
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 commentedon Jun 19, 2019
The file that it's trying to import is, in fact,
.\deps\litex_boards\litex_boards\partner\platforms\fomu_evt.py. I switched to usingpython.autocomplete.extraPathsbecause PYTHONPATH wasn't working.jakebailey commentedon Jun 19, 2019
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 commentedon Jun 19, 2019
I've removed
python.autocomplete.extraPathsand started relying solely onPYTHONPATH. This does work now, in that it's able to find all of the rest of the packages. However,litex_boardsstill gives "Unresolved import".I see the same behavior if I remove the
.envfile and rely onpython.autocomplete.extraPaths.jakebailey commentedon Jun 19, 2019
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 commentedon Jun 19, 2019
I'm now running the daily build. I've submitted a new issue at #1223 (comment)