Python Unresolved import issue

[dmayo77]

When pylinting a file in a big project, it appears as though libraries installed in a venv are not being discovered and thus I'm getting unresolved import issues.

Version: Visual Studio Code Version 1.33.0
Python 2.7.14 (which is what I have to use in my venv)

Sadly, I can't post a screen shot of the issues due to proprietary restrictions.
However, I am able to tab over to the Terminal window, which is pointed to my venv and open python and import each of the libraries that the Problems view indicates are problems from the linting operation without issues.

These aren't pylint errors either they are "Python(unresolved-import)" issues. Neither pytlint, pep8, or flake8 report issues with those imports.

Seems similar to microsoft/vscode-python#3840 which was flagged as being closed, but doesn't appear to be resolved, and I can't post there as that issue is locked.

Could also be simlar to #541 which is 'closed' and #887 which made me spawn this issue.

I'll see if I can reproduce in more a basic way without proprietary libraries in the venv so that it can be fixed and add here with the details.

[dmayo77]

How to reproduce:

1. Create an egg for a library you want to distribute (see https://mrtopf.de/en/a-small-introduction-to-python-eggs/)
2. Install that library
3. Attempt to import that egg in your code.
4. Look at the problems reported by VS Code

Example:

Create the following two files (eggfunc.py and setup.py) in the same folder somewhere deep possibly in your virtual env. (For example, my vevn was at 'c:\venv' and I put them in 'c:\venv\a\a\eggtest'

eggfunc.py
def eggfunc(x, y): return x*y

setup.py
'
#!/usr/bin/env python

a simple egg

from setuptools import setup

setup(
name="the_egg",
version="0.1",
description="A simple egg",
author='you',
author_email="[email protected]",
url="http://bogus/",
packages=[""])
'

Then in your virtual environment, navigate to the folder where those two files, create an egg and then install it.

python setup.py bdist_egg
python setup.py install

Note that the_egg-0.1-pyX.X.egg is now installed in the site_packages folder

Now, in Visual Studio code, create a 'simpletest.py' file in the root of some other folder in your venv, making sure Visual Studio is setup to use that venv appropriately.

simpletest.py
`
""" a basic test to track down import issue """
from the_egg import eggfunc

if name == 'main':
print eggfunc.eggfunc(1, 2)
`

Note in the PROBLEMS output in Visual Studio code, you'll get:

• Unable to import 'the_egg'
• unresolved import 'the_egg'
• Undefined variable: 'eggfunc'

But if you go to the TERMINAL and type in 'python simpletest.py' the code will work just fine.

[dmayo77]

Sorry about the formatting, but hopefully you get the gist.

[tab-cmd]

Same happens to me on V1.33.1 and Python 2.7.10. Same output as #887

[charce36]

I have the same problem, any solution ?

[jakebailey]

We don't yet support egg files (#196), so these types of imports aren't yet going to work.

[zgoda-mobica]

I have the same symptoms in test modules. Package is installed in current conda environment with pip install -e ., symbols are perfectly importable using basic REPL yet I still get unresolved import reported and none of IS functions work.

import pytest

from mypkg.convert.fields import bool2s, none2empty, sq2two

Package is installed properly, code runs fine. Normal code that does relative imports from source tree works fine too.

[charce36]

I resolved installing Ubuntu 18.04

[jakebailey]

If these are all related to editable installs (I don't think they are, not completely), then we currently haven't worked that out yet either. #989

[OllieKampo]

I also have a similar problem, if I try to import any other python file it always says "unresolved" even though when I run it it works just fine...
Can someone just tell me how to disable this annoying green highlighting all over my code?

[jakebailey]

https://github.com/Microsoft/python-language-server#linting-options-diagnostics

{
    "python.analysis.disabled": ["unresolved-import", "undefined-variable"]
}

But disabling the messages won't solve the problem of the language server not finding dependencies, so the analysis will not be any better. Your issue doesn't sound the same as this issue, if it's affecting every import (and not just editable installed ones), so if you have a test project and can make a new issue, that'd be appreciated.

[OllieKampo]

Edit: Sorry I've just realised you said to make a new issue, if this is not a simple fix then I will do that, and delete this comment.

Thank you for your reply Jake.
Its hard to explain the exact issue and I don't know all the correct terminology, i'm afraid I was also a bit frustrated when I posted my original comment so apologies for that.
I'm a PhD computer science student but my masters was in mechanical engineering so I sometimes make simple mistakes with this kind of stuff which may be the issue here.

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

Any ideas?

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

Any ideas?

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

[OllieKampo]

@chudytom Yes I am unsure what this "editable install" thing is as well and whether I am using it or not?
I have not had a reply on this thread so I created a new issue https://github.com/microsoft/python-language-server/issues/1099.

[chudytom]

@chudytom Yes I am unsure what this "editable install" thing is as well and whether I am using it or not?
I have not had a reply on this thread so I created a new issue https://github.com/microsoft/python-language-server/issues/1099.

Greate idea. Just please fix the link because when I click on it, it doesn't redirect me properly. I had to copy it manually.

[sabretus]

I have the same problem, V1.34.0, python3.7.2, MacOS 10.14.5

[mikemac8888]

I try this extension every 6 months but bugs like this are pervasive. I have disabled all 6 available linters and these kinds of squiggly line errors which aren't really errors continue to arise. I would love a way to completely disable all visual notes in vscode from the python extension. Sadly, another six months disabling the python extension entirely.

[jakebailey]

My previous comment in the thread shows how to disable these messages: #918 (comment)

If you don't want anything from the LS, you can disable any of the ones listed in our README, though note that "unresolved import" is special in that it means that the LS wasn't able to find an import, so the analysis quality will suffer (hence why we show it).

I'm going to be looking into editable installs next, and a ZenHub epic which links all the issues together is here: #1139 (though I'm not sure how egg files will play into that)

[egabrum]

I'm going to be looking into editable installs next, and a ZenHub epic which links all the issues together is here: #1139 (though I'm not sure how egg files will play into that)

Great news! I appreciate the work you guys do, but this import issue is a deal breaker for quite a few of us, I believe.

[gatopeich]

Still happening to me on v1.35.1 / Python 3.7 / Linux

• > reload window fixes it. Confirmed
  (first time it was after killing a python process that was taking 100% CPU, but it seems unrelated)

[jakebailey]

The 100% usage from the python process is likely unrelated; if it happens again I'd appreciate it if you could use ps or top to find the arguments given to that script and open a new issue for us to look at (so we can figure out which module is hanging when being inspected).

[Luis-Palacios]

Is there any news on this? I'm having the same issue 😞

[jakebailey]

I'm going through this and related issues, and for the most part you can fix things by setting extraPaths to tell us more directories to use as import roots, for example:

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

If you have more folders, you can list them all, and things should work.

However, this doesn't seem to work when a package gets installed as editable. I believe this has something to do with how the interpreter's own default search paths get modified and how we merge all of this configuration together. I'm currently just going through all of the test projects everyone has provided to get a good view on the unresolved imports first before trying to nail that one.

[jakebailey]

At the moment, our current recommendation is to use the extraPaths configuration to point the LS to your import roots. See the new documentation here: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#unresolved-import-warnings

A fix to editable installs was merged in #1183 (v0.3.1+), and will be available in the daily download channel shortly. To switch to this for testing, you can set:

"python.analysis.downloadChannel": "daily"

[pradyunsg]

@jakebailey Thanks for the update on the fix! :D

Is there an estimate for when this might make it to the default/stable channel? Do I need to be on an Insiders build to use the daily download channel?

It'd also probably be helpful, to update microsoft/vscode-python#3840 to link here.

[jakebailey]

Probably within a couple days. There are some changes in 0.3.0+ that we're trying to ensure aren't causing other issues.

You do not need the insiders build to run the daily channel, just place the config in your settings and reload.

[chudytom]

@pradyunsg try the daily channel with the fix for editable installs. I've been using it for about a week and everything works nice and smooth.
Of course, don't forget to add your library to extraPaths.

[mattlefevre]

I did; I even tried adding each sub-folder to it (in a few different ways, because I was getting desperate and was willing to try anything). Here's all the stuff I added to extraPaths:

"python.autoComplete.extraPaths": [
        "./core",
        "./core/posts",
        "./core/users",
        "./posts",
        "./users"
    ],

Is that formatted correctly? I know I don't need both "./core/posts and "./posts", but I was just trying anything to see if it helped.

[jakebailey]

Of those, I think only ./core should be required... Definitely not the last two, but unless you're relying on absolute imports of both posts.something and something, you should only have the one. Anything past that seems very strange.

[egabrum]

I was wondering, regarding the editable installs, if python can find those modules, why can't the language server and I need to add them to the extra paths?

I can live with that, but it can get annoying if, as me, you work with a lot of editable installs and switch back and forth between editable and packaged.

[mattlefevre]

That's what I thought. I've tried both of these configurations (separately) with no luck:

 "python.autoComplete.extraPaths": [
        "./core",
        "./core/posts",
        "./core/users",
    ],

 "python.autoComplete.extraPaths": [
        "./core",
    ],

[jakebailey]

@egabrum

Editable installs use pth files, which are pretty powerful (can execute any python code at startup before any user code ever runs, but usually just contain paths) and are hard to deal with from an analysis point of view. All we can do right now is ask the interpreter "what are your paths", but the interpreter tells us this editable-installed code is a site package (because that's how pth files work), hence a configuration to tell us "no, actually this is my code".

I'd like to try and remove the extraPaths requirement, but to do that I'm going to have to research a way to distinguish what pth files are just modifying paths for the user code, which ones are doing things for libraries (matplotlib ships one which does some funky stuff), and so on, with potentially more issues. Just assuming that anything that is within the workspace is user code will not work; we can't just assume any path that lives in the workspace is user code (people put venvs in the same dir as their code).

The language server is not the interpreter. It doesn't execute the code, doesn't know if some file is supposed to be a script (and has special paths added on), can't handle most at-runtime sys.path modifications, etc, and must do everything statically. I opened #1213 to track trying to improve our search path handling, but it's not as simple as "if python can do it then so can we" when we aren't actually executing the code, just trying to provide suggestions by viewing files.

@mattlefevre I'd appreciate it if you could enable trace logging and upload a copy of your logs. If your code is somewhere to test, that would be extremely helpful. I mainly want to see the search paths reported.

[mattlefevre]

Here's the repo I'm working on: https://github.com/mattlefevre/book-blog

I briefly looking into how to enable trace logging, but all I could find is how to use the debugger in VSC (still useful, but not what I was looking for).

[pradyunsg]

@jakebailey if the main concern is people putting virtualenv in the project folders and getting confused on that, would it make sense to statically try to detect whether a path is in one?

[jakebailey]

@mattlefevre See: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#filing-an-issue I'll look at that test case tomorrow and see what's going on. (Everyone who's provided test cases for the other path issues are fixed, but it's the more complicated cases where conveniently people can't share the code... 😛 )

@pradyunsg Probably, but it's a bit tough to determine what is the interpreter's path. If an editable install is performed, then it will start saying things normally outside of its own path is "interpreter". It's going to require research and a big list of cases to get that sorted out. Note that if people are writing packages and not using editable installs, then the language server is going to have no way at all of knowing that imports are relative to another directory. It might be the case that extraPaths is required no matter what.

[gatopeich]

On a perfectly working setup (using extraPaths) , this keeps happening after having vscode open for a few days.
Big clue is: Reloading the window fixes it!

[mattlefevre]

I've got a crazy amount of log information at this point (yay!), and I don't think pasting it all in here would work out (the initial loading of VSC is about 3500 lines). I'm not sure exactly what you need, @jakebailey , but here's all of the initial informational logs:

Starting Microsoft Python language server.
Downloading https://pvsc.azureedge.net/python-language-server-daily/Python-Language-Server-win-x64.0.3.18.nupkg... ##########Linting Output - pylint##########
complete
Unpacking archive... ##########Linting Output - pylint##########
done
[Info  - 3:59:16 PM] Analysis cache path: C:\Users\mlefevre\AppData\Local\Microsoft\Python Language Server
[Info  - 3:59:17 PM] GetCurrentSearchPaths C:\Users\mlefevre\.virtualenvs\ambersite-fSB87Qgi\Scripts\python.exe 
[Info  - 3:59:17 PM] Interpreter search paths:
[Info  - 3:59:17 PM]     \python
[Info  - 3:59:17 PM]     \python\pyspark
[Info  - 3:59:17 PM]     c:\users\mlefevre\.virtualenvs\ambersite-fsb87qgi\lib
[Info  - 3:59:17 PM]     c:\users\mlefevre\.virtualenvs\ambersite-fsb87qgi\scripts
[Info  - 3:59:17 PM]     c:\users\mlefevre\appdata\local\programs\python\python37-32\lib
[Info  - 3:59:17 PM]     c:\users\mlefevre\appdata\local\programs\python\python37-32\dlls
[Info  - 3:59:17 PM]     c:\users\mlefevre\.virtualenvs\ambersite-fsb87qgi
[Info  - 3:59:17 PM]     c:\users\mlefevre\.virtualenvs\ambersite-fsb87qgi\lib\site-packages
[Info  - 3:59:17 PM] User search paths:
[Info  - 3:59:29 PM] Microsoft Python Language Server version 0.3.18.0
[Info  - 3:59:29 PM] Initializing for C:\Users\mlefevre\.virtualenvs\ambersite-fSB87Qgi\Scripts\python.exe

Were there any other specific logs I should include here? Or did you want me to attach the entire set of initial logs as a .txt file?

[jakebailey]

The entire thing, but for now I'm more concerned about what those weird \python \python\pyspark paths are. And are those logs without any extraPath configuration? ./core in that list should be making it show up in user search paths.

I haven't yet had time to look at your case yet (filing other issues and making sure 0.3 is okay to go live), but will be doing so next.

[mattlefevre]

I definitely have ./core in my extraPaths. Here are the last few lines of my settings file. Is that all set up right?

    "python.jediEnabled": false,
    "python.autoComplete.extraPaths": [
        "./core",
    ],
    "python.analysis.downloadChannel": "daily",
    "python.analysis.logLevel": "Trace",

As far as the \python and \python\pyspark paths... I'm not sure what those are either?

[jakebailey]

You have that in your global user settings, or the workspace settings? The other three are fine in the user settings, but since ./core is a project-specific thing, I'd expect that to be in .vscode/settings.json.

[mattlefevre]

@jakebailey - Moving that to the workspace settings seems to have cleared everything up! I honestly didn't realize there were separate settings.... 🤦‍♂️

Thank you! You're my hero!

[jakebailey]

This issue has been stale for more than a month; I'm going to close it.

If you're still having unresolved import issues, please check the docs here to see if extraPaths or PYTHONPATH are enough for you: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#unresolved-import-warnings

If you're still having issues after trying that, please open a new issue with your case so we can look at it individually. We know there is still more work to be done when it comes to our import system (#443, #1360, others), but it's difficult to handle the varying cases all in one place.

Thanks!

[chiboreache]

+1

[stevenlis]

@jakebailey The issue has always been with me...

[jakebailey]

Please file a new issue. This issue is 9 months old and was about unresolved imports in user code; requests is a third party library.

[larsjuetten]

I'm going through this and related issues, and for the most part you can fix things by setting extraPaths to tell us more directories to use as import roots, for example:

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

If you have more folders, you can list them all, and things should work.

However, this doesn't seem to work when a package gets installed as editable. I believe this has something to do with how the interpreter's own default search paths get modified and how we merge all of this configuration together. I'm currently just going through all of the test projects everyone has provided to get a good view on the unresolved imports first before trying to nail that one.

This did exactly solve the problem I was facing.
Multiple repos including python-files and vscode got somehow confused. Python-wise (debugging and such) it was working and vscode was able to follow my breakpoint. But my linter (flake8) was complaining about unresolved imports and I could not follow "Go To Definition F12" ...
After introducing this extraPaths it works like charm! :)

Thx!