[PEAK] Packaging peak apps

[Bob Ippolito]

On Feb 1, 2005, at 14:48, Phillip J. Eby wrote:

> At 09:11 PM 2/1/05 +0200, alexander smishlajev wrote:
>> Phillip J. Eby wrote, at 08.10.2004 20:33:
>>> '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).
>>
>> with current cvs checkout, i cannot run PEAK from zip file:
>>
>>   File "peak\running\commands.pyc", line 342, in __call__
>>   File "peak\running\commands.pyc", line 432, in interpret
>>   File "peak\binding\components.pyc", line 397, in lookupComponent
>>   File "peak\naming\names.pyc", line 198, in findComponent
>>   File "peak\naming\api.pyc", line 53, in lookup
>>   File "peak\naming\api.pyc", line 34, in InitialContext
>>   File "peak\naming\spi.pyc", line 61, in getInitialContext
>>   File "peak\core.pyc", line 235, in __call__
>>   File "peak\config\config_components.pyc", line 402, in lookup
>> peak.exceptions.NameNotFound: peak.naming.initialContextFactory 
>> [resolvedObj=<peak.running.commands.ZConfigInterpreter object at 
>> 0x00CBDB50>]
>>
>> if i add moduleName to self.path in ImportLoaderFactory, this name is 
>> found (zipfile contains peak.ini is in 'peak' package directory).
>
> Yeah, I just found out about this the other day, when I realized I had 
> misread PEP 302's specification about how the paths are supposed to 
> work.  More precisely, what needs to be added is the module's 
> __file__.  I will try to fix that this evening.
>
> FYI, on a related note, see 
> http://peak.telecommunity.com/DevCenter/PythonEggs for some work Bob 
> Ippolito and I are doing on making it possible to run arbitrary C 
> extensions from zipfiles; when the work is finished (hopefully by 
> PyCon), it should be possible to distribute PEAK entirely within a 
> zipfile, and PEAK may begin splitting its distribution into smaller 
> pieces, each in its own zipfile.

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.

-bob