[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