[PEAK] Packaging peak apps

[Phillip J. Eby]

At 10:31 AM 9/28/04 +0200, Roché Compaan wrote:
>Phillip J. Eby wrote:
>>At 10:43 AM 9/27/04 +0200, Roché Compaan wrote:
>>
>>>Basically the peak script:
>>>
>>>from peak.running import commands
>>>commands.runMain( commands.Bootstrap )
>>>
>>>I am building an exe from run.py with py2exe for testing purposes. I end 
>>>up with run.exe. I get the traceback when calling run.exe from the 
>>>command line.
>>
>>And this is with an up-to-date CVS version of PEAK?  And 
>>'peak/binding/__init__.py' and 'peak/binding/interfaces.py' are in the 
>>zipfile bound to run.exe?
>
>Yep.
>
>>Better yet...  can you give me a location to download your run.exe so I 
>>can investigate?  Thanks.
>
>Attached is a zip of the whole "dist" directory, containing library.zip 
>and run.exe.

As far as I can tell, the issues are caused by the lack of reloading 
support for zipfiles, coupled with the absence of various required modules 
from library.zip.  (For example, library.zip doesn't contain 
peak.binding.api, so that doesn't work.)

Also note that even if your script got to the second line, it would then 
run afoul of the fact that 'config.fileNearModule()' will be broken when 
the modules are in a zipfile.

Really, to run from a zipfile, you not only need the currently non-existent 
Python 2.3.5, but also a version of PEAK that doesn't use fileNearModule() 
in its present form.

My recommendation to you is to try using the procedure at:

    http://peak.telecommunity.com/DevCenter/DistributePeakApplications

but simply delete the .py files to obfuscate the source.

If you can't use this approach, you might try having your application 
extract library.zip to a library directory (if it isn't already), and then 
replace 'library.zip' in sys.path with the name of the library directory 
before doing any other imports.  This isn't perfect, but it might do the 
trick if you don't want to build your own executable as described on the Wiki.

It would certainly be nice, though, to be able to run PEAK applications 
(and PEAK itself) from zip files, so I do intend to get the 
fileNearModule() stuff revised for PEP 302 compatibility.  But it will be 
moot until 2.3.5 and/or 2.4 are available, because correct operation of 
reload() is a must for PEAK's own modules, at a minimum.