-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import "[module]" could not be resolvedPylance (reportMissingImports) #236
Comments
The workspace root is an import root, but it appears you are trying to make each chapter its own project where files are imported there. This warning is important and does have an effect, because Pylance is telling you that we can't resolve your imports and won't offer any completion for those modules. You may want to consider either opening each folder independently (thus making them their own import roots), or trying VS Code's multi-root workspace support if you want to treat every folder as its own individual import root. I'd normally suggest Jedi can do this because its import resolution system is different and tries its best to find imports which match, in this case it finds Also related is #68, microsoft/python-language-server#1602 |
Now I understand. I appreciate your detailed reply. Thank you! |
I think that bug is still valid and applies to any python project that is not keeping its modules inside the root of the project. That is really bad because the best practices are to avoid keeping modules in root and use a folder like Thus we are penalizing anyone that makes use of good practices for layouting python codebases. |
This isn't a bug. You need to configure the tool appropriately. Pylance automatically includes the root path of your workspace. It also automatically adds a subdirectory called |
If it automatically adds a Still, I am pleased that one of the two is working naturally without configuration and I already renamed on recent repository folder from To avoid configuration, ideally pylance could look inside
|
Most published projects don't use src or lib, instead using nothing at all, or a folder name at the top level for their package (e.g. numpy has "numpy", pytorch has "torch") which requires no configuration. When I originally analyzed a bunch of user feedback and repos, I found that it was either a free for all, the "name of the top level module" layout, or src, hence why the feature is as limited as it is (since it can actually hurt people's imports if we're adding too many roots). |
It would really be interesting to get a survey on which versions are used for |
Replace use of lib/ folder with src/ which is preferable as it causes less problems. This solder is also recognized and used by multiple tools without extra configurations. Lib was more problematic because it also happens to be on the default .gitignore file on new repositories. Related: microsoft/pylance-release#236
Replace use of lib/ folder with src/ which is preferable as it causes less problems. This solder is also recognized and used by multiple tools without extra configurations. Lib was more problematic because it also happens to be on the default .gitignore file on new repositories. Related: microsoft/pylance-release#236
I'm still having this error, so I filed a question on StackOverflow. Thanks in advance for your consideration. |
that's not how python behaves with regard to import, so I'd consider this to be a bug. |
My layout is:
My main.py has And when I have VS Code open on the root, Pylance can't find the module "file", yet calling |
Okay but that seems like a fairly standard setup, any reason why it's not supported by default? |
I guess I'm confused; your text layout is compressed so I can't really tell what is nested in what. In general we assume that the workspace root is the root of all imports. We can't really tell what folders are also import roots without configuration, otherwise we'd just be doing lose non-spec imports and/or be unable to tell if an import has failed. |
is there any update on this issue? I tried to add |
This is a closed issue. If extraPaths isn't working for you, please file a new issue; it's very likely not the same. |
no se si con este aporte pueda ayudar a alguno de los que empezamo en la programacion. pero a mi me salia el mismo error en un proyecto de practica y lo resolvi agregando from python.car import Car en mi caso. antes cuando me salia el errro de advertencia (Import "car" could not be resolved) from Python.car import Car if name == "main":
Aqui mi aporte a los que recien estamos en la programacion. Saludos |
Para el problema del import en python a mi lo que me generaba el problema era la extensión Pylance. Lo que hice para solucionarlo: En el settings.json buscar y deshabilitar la línea que dice “python.languageServer”: ‘Pylance’" y listo, espero les funcione. Nota: Para los novatos como yo en VSCODE, para abrir el settings.json, ingresan a la paleta de comandos Ctrl+Shift+P y buscan Open Settings (JSON) |
@alberto301230 You seem to be suggesting that disabling Pylance entirely fixed that issue; we'd of course like to fix it. There's nothing about that code above that shouldn't be working given the right project layout, if you can reproduce this and open a new issue, that would be appreciated. |
@jakebailey I'd consider reopening this issue using @prosenboim's argument. This is not how python searches for modules, which is unexpected behavior, especially when the warning doesn't give a good clue about the |
I don't really know how to apply that argument alone without any good examples, and none were included for that comment. Python's import resolution is very nuanced; it depends on your $PWD, how you run the code (module versus script), the environment itself (pth files, paths, installed namespace packages), at-runtime It's really difficult to capture everyone's behaviors while actually providing useful error messages, which is what we want to be able to do. If there are more examples of projects or layouts we can try and detect, then that is good information. If you'd find it useful to have some sort of suggestion to configure the project based on us going through files and seeing if an import root would fix things, then maybe we can do that too. Maybe we do have to do something looser like jedi (which will resolve practically anything, even if it will crash) with some suggestions for config updates. Back when I was designing the "autoSearchPaths" feature, we found that the bulk of people with import issues were just using But "it doesn't work" or "python doesn't behave this way" is really hard to take action on without additional context. It's frustrating to read comments bumping month old threads, us asking for more info or a new issue so we can properly track and put time into solving it, but then the feedback never happens, and the cycle continues. |
That's fair. Apologies for not including additional context/info. Hopefully this is more helpful. I think the standard Module Search Path should be sufficient for many projects.
As it stands currently, Pylance won't even find my module file in the same directory as a script/main module unless it is in the root of the workspace or I add an
edit: to be even more clear, I'm not sure it's possible for you to recreate |
We certainly implement that algorithm in general, the problem is scripts, which is #253 and is difficult to emulate statically. We don't know for any given file if it's supposed to be a script or not to know that it is supposed to be allowed to import absolutely from the folder in which it is contained (and therefore should not search the workspace root). There's also the other problem that this then means that any other file that It would be interesting to see if we can do some sort of scan to figure out if by modifying extraPaths, imports for a project would be improved, and offer that as a specific suggestion to change the workspace config. But in essence, this is the feedback we wanted on #253. That issue hasn't gained much traction and we've been working on other features like go-to-def tweaks and docstring fixes (both very upvoted). |
looking more through #253 and some of the other issues referenced there, I have a new appreciation for the problem. |
No worries, I appreciate the feedback. I just wish there were a clean way to solve it! Maybe there will be an epiphany some day... |
Inside b.py, I do |
Can you please file a new issue and fill out the bug template with trace logs? What you've written should work so long as you've opened up the folder containing both. |
Is still a problem |
Adding this to the |
If you're still following this thread (versus the linked issues), we have a new hidden option to experiment with a new import resolution mechanism. We'd appreciate feedback there. |
not a Bug??? ├── pkg_folder On main.py: # wrong
from .python_file
# right
from python_file Pylance says its wrong something that is right and right when its wrong, so it is a bug. |
@luizfelipevbll Can you open a new issue for that? If python errors when running it but we show it as valid, then that may be a bug we need to fix. |
Yes, I configured the |
It's strange and inconvenient, VSCode updated today, and I got Pylance which broke by cozy code highlight and add this problem with import, so now I have to add to all of root for every my projects to "python.analysis.extraPaths"? It's strange, all works, then updated and I got a lot of troubles :\ |
I don't know what happened recently but it's working now. |
Just wanted to chime in that it seems if you're using AWS Lambda Layers and storing your module dependencies inside the project folder as documented, Pylance doesn't appear to resolve the relative dependency path, even when I am using a multi-root workspace with fully qualified paths if that makes a difference. Since it doesn't appear I can downgrade from Pylance to the previous Microsoft Language Server (Switching in the VSCode settings still generates the above Pylance error), I'm back to using Jedi (Which isn't a bad thing, all of these LSP Servers work well in some ways, not so great in others) I understand these are technically complex problems that do not have easy solutions. But as feedback intended to be critical but friendly, I tend to run into issues with Python on VSCode every 2-4 months or so, and most of the time it resolves to the module imports system. Because there's a good amount of time time between these issues, I have lost the cognitive memory around the solution, so I have to spend some time trying to fix it. Sometimes it's 30 minutes, sometimes it 3 hours. Having to get back into focus mode after hitting a roadblock like that is a real productivity killer -- If I'm importing a new module somewhere, I have that module in my head to solve something in my code. So when it doesn't resolve, I lose that focused purpose, and then have to really think about where I was later on when it's fixed. I think we can all empathize with each other and say that we've all been there at one point or another. |
Again, this is a closed issue, and I've pointed to two issues where we are currently discussing different project layouts (#68 and #150). A closed issue is really not the place to add to this. That layout in particular would likely function if you pointed |
I think this comment should be pinned at the top of this issue. |
GitHub has no mechanism to do that, I'm afraid. |
This solution seems to have worked for me. I just add |
I have the same problem. My app works even though with this warning but when i deploy it, it dyes :( |
I just changed the interpreter and it is working fine |
This fixed the issue for me, despite vscode reporting that Which appears to be a bug. |
I am learning a Python book, so I created folder for each chapter to storage code. Working directory is as follows:
b.py
When I "open by code" in "book" folder, the Yellow wavy line is below the code "import a".
However, module "a" is really imported and it works well.
If I delete "python.languageServer": "Pylance" and use Jedi, yellow wavy line won't show up.
In addition, if i "open by code" in "chapter1" folder, yellow wavy line won't show up.
The Yellow wavy line doesn't have any effect, but it's a nuisance. Is this a normal reminder?
If the answer is Yes, please ignore my question.
The text was updated successfully, but these errors were encountered: