__init__.py is handled differently than python files in the same path

[smanross]

Environment data

• Language Server version: 2022.6.0
• OS and version: Win 10 Pro 21H2
• Python version: Python x64 3.9.12 (from python.org)

Code Snippet

\\someserver\someshare\someworkspace\someproject\.vscode\settings.json

{
    "python.analysis.extraPaths": [
        "\\\\someserver\\someshare\\someworkspace\\someproject\\pythonlibs",
        "\\\\someserver\\someshare\\someworkspace\\pythonlibs",
    ],
}

\\someserver\someshare\someworkspace\someproject\pythonlibs\somepackage\__init__.py

from mymodule import myfunction

\\someserver\someshare\someworkspace\someproject\pythonlibs\somepackage\somemodule.py

from mymodule import myfunction

Note: mymodule lives in: \\someserver\someshare\someworkspace\pythonlibs

Repro Steps

If I add a workspace specific extrapaths statement in settings.json (as above), the __init__.py throws a reportMissingImports error, but the somemodule.py in the same path does not throw the reportMissingImports error.

Workaround

When I add the extraPaths statement to the user profile settings.json, the reportMissingImports error for __init__.py goes away, but ultimately, I only want to add this specific extraPath for the workspace I am working on.

I wouldn't have assumed that __init__.py would be treated differently than other python files in the same folder.

P.S. I love pylance, and thank you for all the work that's been done on it!!!

[erictraut]

I'm not able to repro the problem you're seeing.

Are you using a multi-root workspace? If so, what are the root directories? I'm assuming that someproject and pythonlibs are the roots.

Let me make sure I have the repro steps correctly. I've created a new workspace. Within that workspace, I create the following:

# someproject/pythonlibs/somepackage/__init__.py
from mymodule import myfunction

# someproject/pythonlibs/somepackage/somemodule.py
from mymodule import myfunction

# pythonlibs/mymodule.py
def myfunction():
    pass

// .vscode/settings.json
{
    "python.analysis.extraPaths": [
        "../someproject/pythonlibs",
        "../pythonlibs"
    ]
}

Note that you should generally not use absolute paths when defining extraPaths. They should typically be relative to the project. You also don't need to use backslashes. Regular slashes are translated as required for the platform and file system you're using.

Let me know if I've replicated the setup correctly. I'm not able to repro any errors, as you can see in this screen shot.

[smanross]

Apologies as I tried to abstract this from a real example while hiding the server names, shares, modules, etc but I believe I have recreated it based on your example of the relative paths.

Note: Because I am accessing this all from UNC paths (a share on another server -- not through a mapped drive), I believe that pylance doesn't like the relative path notation, and instead wants the fully qualified UNC paths in extraPaths but I could totally be wrong -- however, my minimal testing seems to indicate that this is correct).

Also note that I use pylint and pylance, and in order to get pylint to correctly parse everything, I Needed to add this to settings.json, and it correctly identifies imports in __init__.py and somemodule.py.

    "pylint.args": [
        "init-hook=import sys; sys.path.append('\\\\someserver\\someshare\\someproject\\pythonlibs');",
    ],

Further, in substituting the full UNC path in the settings.json above for the relative path notation, all the imports complete correctly (no errors).

Lastly, after mucking around with all this to recreate the example in the way I described it here, the actual __init__.py that I was having problems with is NOT throwing the reportMissingImports error anymore, which has me baffled, and I can only assume that there is something else at play here, because clearly, my initial success in adding extraPaths to the user profile settings.json file did squash the reportMissingImports error (for pylance) while at the same time, pylint didnt show any issues, and now I don't need the user profile settings.json extraPaths entry for pylance to work correctly for the 2 files in the same directory. :( :)

From a further debugging perspective, should I be looking through the trace logs if this happens again? is there something in particular I should be looking for?

I'm totally fine with closing this as not reproducible, but would love the further debugging thoughts.

Please and Thank You for your time.

[smanross]

and here's another screenshot since I never gave you one with the actual problem... This is backwards from the other day.. __init__.py working and the module not working... :(

HTH

[erictraut]

Here's something to try...

Create a file called "pyrightconfig.json" in the root directory of your "pythonlibs" project. Within this config file, add the following:

{
    "verboseOutput": true
}

Now close the project window and reopen it. Look in the Output panel and select the "Python Language Server" from the popup menu to view Pylance's output. You should see additional details about the import resolution failure. This might give us some additional clues about what's happening here.

Does the path you're adding to "python.analysis.extraPaths" point to the same directory "pythonlibs" that I see in the left panel of the VS Code screen shot above? If so, I don't understand why you would need to add the extra paths. The project root is always searched for import resolutions, so specifying it again in extraPaths should be unnecessary.

[smanross]

adding the verboseOutput to pyrightconfig.json doesnt seem to add anything to the output tab.

If I followed correctly, I could just close vscode completely, and then it should read the config change upon reopen.

I also closed all the open file windows, and then reopened then and nothing changed.

Lastly, I changed to another workspace by pressing Ctrl-R and selecting a new project, and then doing the same to move back to this project, and there was no change.

pythonlibs lives at the unc path specified as extraPaths

\\servername\f$\inetpub\pythonlibs

and the workspace is defined like this (there are a few other folders for different websites in there, but for brevity, this should suffice):

{
	"folders": [
		{
			"path": "pythonlibs"
		}
	],
	"settings": {}
}

[smanross]

OK.. I didnt follow your last point until I clicked send on the last comment.

--> removing the extraPaths for this directory has gotten rid of the error. However, putting it back in didnt recreate the error either. :(

I will remove the extraPaths for this folder and continue to monitor. Thanks for the thoughts!!!

EDIT: argh: after putting extraPaths back in, removing the extraPaths DOES make the error reappear.

[smanross]

P.S. based on what I know about UNC paths, there is no "current directory", I.E. you can't "cd \server\share\folder"

I'm going to try all this with mapped drives and see if that makes things work better ...
EDIT: * Initial testing of mapped drive works, no errors (without the extraPaths statement)

However, none of this explains why pylint worked the whole time that I was having problems with pylance.

[heejaechang]

can you provide us complete repro steps with sample project, that will make much easier for us to figure out what is going on.

"can't resolve import" can be affected by many things such as extra path, python search path, project root, multiple workspaces and etc.

it will make much easier for us to figure out if we can have full picture.

[smanross]

Based on my testing, I believe this has to do with a project hosted on another server and accessed by UNC paths.

if I Start-> Run: explorer.exe \\someserver\f$\inetpub

and doubleclick on my workspace file that has multiple folders in it to open vscode...

I get the error for a python module in the same directory as the one I am looking at:

• srm\multisql.py is referenced by srm\aspfunctions.py

Now, I browse to the L: drive that I mapped the share to (in windows explorer) and click on the workspace file to open vscode:
(2nd vscode window now opened and it has aspfunctions.py already opened in it along with some other files)

# this is how I might map that UNC path above
net use L: \\someserver\f$

# now browse to the workspace root in the inetpub folder:

explorer.exe L:\inetpub

# now open/doubleclick the workspace file to open vscode in this workspace

... and I get no error for aspfunctions.py.

I believe the error I originally gave you is similar in that a lot of the projects I work on are on other servers and I access them all by UNC paths (not mapped drives).

Keep in mind that "sometimes" when accessing the UNC paths, pylance doesn't display the modulenotfound error (and I dont know why).

Maybe this graphic better illustrates this issue:

• The one vscode window with the error (far left) was opened from UNC paths, and
• The vscode that has no errors (the one you can see the file menu on) was opened from a mapped drive to the same path (same extrapaths statement on it pointing to UNC paths).

Keep in mind that I have extraPaths statements pointing to the project folders as "UNC paths" as shown above because when I access the projects via UNC paths, I want it to work correctly, and the "relative path" naming that was suggested didnt work as shown by the graphic from 8 days ago (6/5?/2022) when accessing the workspace from UNC paths.

Does this better explain what I am seeing and how to reproduce it?

Steven

[smanross]

sample project:

The workspace root would be at: \\someserver\f$\Inetpub

Extract pythonlibs to: \\someserver\f$\Inetpub so that sample.this and sample.that are at:

\\someserver\f$\inetpub\pythonlibs\sample\this.py | that.py

pythonlibs.zip

place these files on a shared folder, create a workspace file on another server and access it either by a mapped drive or via a UNC path to see how pylance behaves differently.

P.S. This settings.json does not have the extra paths statement in it because you suggested that pylance should not need the extraPaths statement for files in the same directory and only has mods for extra paths to search for pylint in it.

HTH

[heejaechang]

I am still not sure how I recreate the issue. your zip file only contains 1 folder and no multiroot workspaces. and description on the above and below doesn't use same folder name.

and Most of all, can you provide us some logs as described in the troubleshooting guide?

if you provide that log, it will make us a bit more context to understand your environment. and please, provide us the full log as it is without any edit.

[heejaechang]

@smanross figured out the repro steps. it was due to how we handle uri to path conversion when the given uri is UNC.

[smanross]

I'm sorry this was so difficult to figure out the reproduction steps and am glad we are on the same page now!!!

Thank you for sticking with this issue and I will look forward to seeing a fix!

[rchiodo]

This issue has been fixed in prerelease version 2022.11.21, which we've just released. You can find the changelog here: CHANGELOG.md