[PEAK] Packaging peak apps

Bob Ippolito bob at redivi.com
Tue Feb 1 18:07:11 EST 2005


On Feb 1, 2005, at 17:32, Phillip J. Eby wrote:

> At 03:02 PM 2/1/05 -0500, Bob Ippolito wrote:
>> Note that it's not just about being able to run arbitrary extensions, 
>> that is just a bonus.  It significantly cleans up the API for finding 
>> non-code resources, allows for package selection based on version and 
>> platform information, etc.  With the pkg_resources API you can (even 
>> with the current primitive implementation) do:
>>
>> pkg_resources.resource_string('peak', 'peak.ini')
>>
>> and it will do the right thing, whether or not PEAK is in a zip file.
>
> The reason I said it the way I did is that PEAK already has support 
> for finding its own stuff in a .zip file, it's just broken.  :)  
> Fixing the bug that Alexander mentioned will allow PEAK to handle 
> non-code resources correctly, so the main thing that .egg support adds 
> (to PEAK) is supporting extensions, and files that have to be read 
> from C code.
>
> For non-PEAK applications, of course the rest of the pkg_resources API 
> is also a bonus.  :)

I also noticed that zipimport.zipimporter expects PEP 302 fullname's to 
be in 'foo/bar' format for module names, not 'foo.bar' (get_source, 
get_code, is_package).. which is probably a bug.

Do you know of any other importers?  I'm kinda tempted to make 
LoaderDistribution fix-up the fullname's for zipimport.zipimporter 
compatibility... but I'm not sure if it would break any other ones.

-bob




More information about the PEAK mailing list