The generated-pth.py is what is created when installing a namespace package. These files are loaded on the auto-import of the site module to make sure Python knows where to find everything. There's a slight bug in this, however, that causes a problem. What happens if you have an __init__.py
file in one of the directories along the way?
We ran into this in Armstrong creating our armstrong.apps.audio.backends.*
packages. The code that's checks to see if there's an __init__.py
in the directory, and if there is it doesn't pre-populate it with a fake module. The problem is that those modules might not actually be imported and loaded yet. See where this is going yet?
This code creates the following in sys.modules
:
sys.modules["armstrong"] = types.ModuleType("armstrong") sys.modules["armstrong"].apps = types.ModuleType("armstrong.apps") sys.modules["armstrong.apps"] = sys.module["armstrong"].apps # skip armstrong.apps.audio, we know how to load it sys.modules["armstrong.apps.audio"].backends = types.ModuleType("armstrong.apps.audio.backends") # NOW PANIC AND FREAK OUT!!
The hacky fix? Add an empty armstrong/apps/audios/backends/__init__.py
, but that should not be necessary. The namespace_packages
code is supposed to handle that type of thing for you. Instead, I think the file what-it-should-be.py
is what should be generated.
So tell me, why not? I feel like I've missed something here. Well, other than Python shouldn't import things by default, but... it's already sorta doing that by pre-populating the sys.modules
.
Note
This is a preliminary version of a blog post for TravisSwicegood.com. It's created under the CC by-at-nc.
3 years ago, this commit caused me to lose my afternoon.