[PEAK] Packaging peak apps

[Bob Ippolito]

On Oct 8, 2004, at 1:33 PM, Phillip J. Eby wrote:

> At 11:18 AM 9/28/04 -0400, Phillip J. Eby wrote:
>> 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.
>
> FYI, that version of PEAK is now in CVS.  'config.fileNearModule()' is 
> now deprecated and its usage in the PEAK libraries has been converted 
> to 'config.packageFile()', which is able to work with PEP 302 loaders 
> that have a 'get_data()' method (such as the zipfile import loader in 
> Python 2.3 and up).
>
> This *doesn't* address the lazy-import issue with Python's reload() 
> bugs, but it *does* mean that PEAK should be able to read all its 
> configuration files, schemas, etc. from a zipfile that has them 
> compressed within the appropriate subdirectories.  Likewise, PEAK 
> applications that use 'pkgfile:' URLs should also be able to work 
> zipped.
>
> So, it seems the only hurdle left to being able to use PEAK with 
> py2exe and friends is the reload() fixes.  (And possibly with getting 
> py2exe to zip up package data files, in case it currently only puts 
> modules in the zipfile.)

There is currently no standard way to determine what files a package 
actually *needs*, versus what files happen to be in there (such as 
documentation, version control junk, etc.)... so correctly packaging up 
stuff that requires data files is going to require developing some 
manifest file or something that says "i need these files".  Preferably 
this file would be parseable without eval'ing arbitrary python code.

If you come up with something that makes sense, I'll support usage of 
it in py2app and try and get it supported by at least Twisted and 
pygame.

-bob