unresolved imports #1085

Activity

1. jakebailey commented on May 15, 2019

   

   Jake Bailey (jakebailey)

   on May 15, 2019

   Member

   More actions

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

   👍React with 👍1Reacted by Seyyed Hossein Hasanpour
2. tmdag commented on May 15, 2019

   

   Albert Szostkiewicz (tmdag)

   on May 15, 2019

   More actions

   thanks Jake Bailey (@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 ?
3. jakebailey commented on May 15, 2019

   

   Jake Bailey (jakebailey)

   on May 15, 2019

   Member

   More actions

   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).
4. tmdag commented on May 16, 2019

   

   Albert Szostkiewicz (tmdag)

   on May 16, 2019

   Last edited by tmdag

   More actions

   Jake Bailey (@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.
5. jakebailey commented on May 16, 2019

   

   Jake Bailey (jakebailey)

   on May 16, 2019

   Member

   More actions

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

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

   👍React with 👍10Reacted by PeakLu, Peter Boothroyd, 赵鹏, Lu Zhao, Tim Schwenke, Jesse Shirley, Aline Cavalcante, Zhida Zhang, Reynaldi Aditia and Victor Badenas

   😄React with 😄2Reacted by Tim Schwenke and TravelingPanda
6. byteroll commented on May 19, 2019

   

   PeakLu (byteroll)

   on May 19, 2019

   More actions

   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.
7. tmdag commented on May 19, 2019

   

   Albert Szostkiewicz (tmdag)

   on May 19, 2019

   More actions

   works great! thank you!
8. Jake Bailey (jakebailey)

   closed this as completedin #1183on Jun 7, 2019
9. jakebailey commented on Jun 7, 2019

   

   Jake Bailey (jakebailey)

   on Jun 7, 2019

   Member

   More actions

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

    self-assigned this

    on Jun 7, 2019
11. Jake Bailey (jakebailey)

    added this to the June 2019.1 milestone on Jun 7, 2019
12. michaelkolber commented on Aug 12, 2019

    

    Michael Kolber (michaelkolber)

    on Aug 12, 2019

    More actions

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

    Jake Bailey (@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).
13. jakebailey commented on Aug 12, 2019

    

    Jake Bailey (jakebailey)

    on Aug 12, 2019

    Member

    More actions

    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).
14. michaelkolber commented on Aug 12, 2019

    

    Michael Kolber (michaelkolber)

    on Aug 12, 2019

    More actions

    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?
15. jakebailey commented on Aug 12, 2019

    

    Jake Bailey (jakebailey)

    on Aug 12, 2019

    Member

    More actions

    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.
16. michaelkolber commented on Aug 12, 2019

    

    Michael Kolber (michaelkolber)

    on Aug 12, 2019

    More actions

    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?
17. jakebailey commented on Aug 12, 2019

    

    Jake Bailey (jakebailey)

    on Aug 12, 2019

    Last edited by jakebailey

    Member

    More actions

    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"].

    👍React with 👍1Reacted by Michael Kolber
18. trallnag commented on Mar 18, 2020

    

    Tim Schwenke (trallnag)

    on Mar 18, 2020

    More actions

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

    😕React with 😕1Reacted by Madhukar Mishra
19. Ircon commented on Apr 19, 2020

    

    Ircon (Ircon)

    on Apr 19, 2020

    More actions

    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?
20. jakebailey commented on Apr 20, 2020

    

    Jake Bailey (jakebailey)

    on Apr 20, 2020

    Member

    More actions

    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.

    👍React with 👍1Reacted by Tim Schwenke
21. Ircon commented on Apr 20, 2020

    

    Ircon (Ircon)

    on Apr 20, 2020

    More actions

    Thank you for your explanation.
22. brando90 commented on Jun 24, 2020

    

    Brando Miranda (brando90)

    on Jun 24, 2020

    More actions

    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
23. brando90 commented on Jun 25, 2020

    

    Brando Miranda (brando90)

    on Jun 25, 2020

    More actions

    Jake Bailey (@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.
24. jakebailey commented on Jun 25, 2020

    

    Jake Bailey (jakebailey)

    on Jun 25, 2020

    Last edited by jakebailey

    Member

    More actions

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