[PEAK] using peak from a zip file

Stephen Haberman stephen at beachead.com
Thu Apr 1 08:22:38 EST 2004


I'm building an application with PEAK that I'd like to be super easy to
install. So I was thinking of making a zip file of build/lib.win32-2.3,
say peak-head.zip, and putting it on the sys.path so that Windows users
wouldn't have to 'setup.py build'/etc.

But peak.running.commands is not getting loaded, it seems to want to
come from PYTHON_HOME\lib\commands.pyc.

I've attached the output of my run script with does:

from peak.api import running
print '\n'.join(['%s: %s' % (key, str(value))
    for key,value in sys.modules.items()
    if key.startswith('peak')]) from
wack.commands import ServerCommand

But the ServerCommand import gives an AttributeError saying LazyModule
has no attribute 'AbstractCommand'.

The attached output shows that some of the initial, perhaps non-lazy,
modules are indeed being loaded from peak-head.zip. The others are
listed as built-in, which I assume is a side affect of not being loaded

So, I changed line 197 of util.imports.py to print the 'loading...' +
module.__name__ right before reload(module) and then 'to...' + module
right after reload(module), which you can see in the output.

The module goes in as peak.running.commands, even looks like it causes
peak.running to be loaded as well, but then right after the reload(<lazy
peak.running.commands>) call, it comes out as being from

I've poked around in the imports.py code but haven't seen anything
obvious. My current best guess is that reload is broken and not checking
zip files on the sys.path, but that seems, well, unlikely, and that it's
probably either something I'm doing or something the lazy module is or
is not doing.

Any insights to what I'm doing wrong, if anything? Or should I just fall
back on a non-zipped copy of PEAK on sys.path?


More information about the PEAK mailing list