VSCode unable to resolve imports from secondary airflow namespace package in monorepo with duplicate package names
#6649
Comments
|
We have this same problem. We have multiple packages at the root of the workspace the provide modules into the same top level modules, for example: Some submodule names under moduleA may exist in both packages, but the py files are different. We have this in settings.json Imports for moduleA and submodules are resolved under pkg1, but not pkg2. |
not sure I understand you correctly. you mean when there are the 2 same names it always go to the first? or when there is only 1, it doesn't find it? can you give us full example, rather than just describing it? ... if you are talking about same name existing in 2 places, what gets resolved is based on order of search path in and the behavior should be same for runtime. it will get resolved to the one show up first in |
|
@JDarDagran can you show give us log as described in here - https://github.com/microsoft/pylance-release/wiki/Collecting-data-for-an-investigation.#collecting-trace-logs - this will give us some insight on how pylance is configured in your dev env. ... that said, I think the issue is your mono repo is not recognized correctly to us, especially if you are using multi root workspace with editable install between roots. the log above can help us understand your env. meanwhile, these documents could help you understand some of how pylance set up workspace and how to manually tweak it for your env. https://github.com/microsoft/pylance-release/wiki/Opening-Large-Workspaces-in-VS-Code#manually-configure-your-workspace |
heejaechang
added
the
waiting for user response
|
The order of paths in extraPaths does not matter, it always resolves the same modules, in this example the modules under pkg1. If I remove pkg1 from extraPaths, then the module imports for modules under pkg2 resolve. If I add pkg1 back in, module imports for it resolve but not for pkg2. Again, it does not matter what the order in extraPaths, in my case only pkg1 module imports resolve. Believe me, I have scoured those articles are more regarding this issue. I will work on getting you a log. |
|
our code says the order matter so not sure how it doesn't matter in your case. but here is what I see Recording.2025-01-08.155701.mp4and this is the behavior of python interpreter as well. when there are multiple modules with same name in multiple import roots (ex, each folder in |
|
At the start of the collected log below, pkg1 modules were resolved and its path was the second item in the extraPaths setting. When I removed the pkg1 path from extraPaths, pkg2 modules became resolved and pkg1 modules became unresolved. |
|
this is |
|
by the way, this seems different than your |
|
Yes, pkg1 and pkg2 are examples. Here's an example with a single path in extraPaths, which resolves some of the imports (e.g. When I add the suggested path to resolve the other imports, it becomes the second item in the list. The other imports are now resolved, and the previously resolved imports are not. For example, |
|
This is what I have set in settings.json, but I still only have info messages in the output. |
|
I restarted vscode and got more detail. The restart happened with the following extraPaths: Here are attempts to resolve two unresolved imports. Interestingly, it does resolve them, but appears to continue on. |
|
please, provide full log as the doc I linked above said, everything from the start of service. otherwise, it would hard for us to figure out. |
|
The log is over 15k lines long, and I'm not willing to post it here. Is there another way I can provide the log to you? |
|
you can send it to heejae.chang at microsoft dot com |
|
so I looked the log, the issue is missing what's happening is, our import resolver is going through import roots and resolved that's why and I just confirmed that's runtime behavior as well. I didn't look other cases, but try fix this issue (not just this one but other module/packages having the same issue) and see whether you still having import resolve issue. by the way, if you still have issue, we would appreciate if you create a new issue rather than keep re-using other people's issue. |
|
Excellent, thank you! I thought this was the same issue, but I will submit new issues in the future. |
Type: Bug
Behaviour
VSCode successfully recognizes and imports modules from the main airflow package but doesn’t detect imports from the secondary airflow namespace package.
Steps to reproduce:
uv syncuv pip install -e . -e ./providers -e ./task_sdkpip install -e . -e ./providers -e ./task_sdk --config-setting editable_mode=compatfrom airflow.sdkorairflow.providers.Diagnostic data
Extension version: 2024.18.0
VS Code version: Code 1.95.1 (Universal) (65edc4939843c90c34d61f4ce11704f09d3e5cb6, 2024-10-31T05:14:54.222Z)
OS version: Darwin arm64 23.4.0
Modes:
python.languageServersetting: DefaultUser Settings
System Info
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off
The text was updated successfully, but these errors were encountered: