CODEWITHSUNDEEP
pythonpython-3.xwindowspython-importpdb
AJM
AJM

Reputation: 1763

Debugging a Python import failure (ModuleNotFoundError)

Short:

I have been trying to debug a ModuleNotFoundError that is occuring in one of my local repo clones.

More detail:

I have two clones of the same repo. Both have the master branch checked out at present. There is a Python script that I want to run which imports various modules, which import other modules, etc. In the first repo clone, I get ModuleNotFoundError: No module named 'TheModuleInQuestion'. In the second clone, the script successfully imports everything it needs and runs without error - DESPITE sys.path containing no repo-specific foldernames, and despite the fact that all of the files which might be being imported are present in the first repo too.

I would like to debug this, preferably with pdb, by observing the import process, the order in which folders are searched, and the path of the imported module in the second repo. I have looked at pdb user guides online, but found nothing relevant to this particular use-case. How would I go about doing this?

More information

All of my repo clones are in subfolders of ~/git (or, since I'm using Git Bash on Windows 10, C:\users\myusername\git)

I'm using Python 3.6.5 32-bit. This isn't the latest version, it's the one specified by the company for compatibility reasons with some package or other.

>>> import sys
>>> sys.path
['', 'C:\\Python36\\python36.zip', 'C:\\Python36\\DLLs', 'C:\\Python36\\lib', 'C:\\Python36', 'C:\\Python36\\lib\\site-packages', 'c:\\users\\myusername\\downloads\\pyopenssl-master\\src']

After getting

ModuleNotFoundError: No module named 'TheModuleInQuestion'

I have searched my repo clones for files with names beginning 'TheModuleInQuestion'. There is no 'The ModuleInQuestion.py' in any of these. Various folders contain:

Upvotes: 6

Views: 10633

Answers (1)

bruno desthuilliers
bruno desthuilliers

Reputation: 77892

Python modules can be either pure Python (.py files) or binary lib files (.so on linux, .dll on Windows), so chances are the module you're looking for is "TheModuleInQuestion.dll".

wrt/ "debugging the import process with pdb", you won't be able to do much here I'm afraid - pdb only works on pure python code, and all the import system is builtin (part of the python.exe runtime).

You can still answer two of your questions nonetheless:

the order in which folders are searched

That's sys.path, quite simply. That's exactly what it defines: the order in which folders are searched. FWIW, the fact that it contains "no repo-specific foldernames" is normal and expected.

and the path of the imported module in the second repo

go to your second repo folder, open a python shell and type

>>> import TheModuleInQuestion
>>> print(TheModuleInQuestion)

Now if both local repos are clones of the same remote and are on the same branch (are they at the same revision ?), there shouldn't be much diff between them. I don't know what diff tools are available on Windows, but the first thing I'd do here would be to diff the repos.

If nothing obvious comes out of it, I would then check files and folders permissions (specially on this "TheModuleInQuestion.xxx" files of course, but also on the whole path leading to it).

And finally - if nothing else solved the issue - I would make a 3rd clone repo and test it (eventually testing different revisions).

Oh and yes: cleaning stales .pyc files is often a good idea. I don't think it will solve anything in your case (if TheModuleInQuestion is a dll...), but that's still a good idea - sometimes a deleted .py file leaves a stale .pyc, and then all bets are off ;-)

Upvotes: 2

Related Questions