[Chandler-dev] Re: Parcel loading vs. Egg loading

[Brian Kirsch]

Sure I understand that :)

It was more of a question of do we want to allow third party developers 
to install translations via the installParcel
mechanism as a convience.

My personal opinion at this point is no!  Lets just use eggs and have 
that be our one and only means of doing resource
and localization registration.

-Brian

Brian Kirsch -  Cosmo Developer / Chandler Internationalization Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org



Phillip J. Eby wrote:

> At 01:05 PM 6/8/2006 -1000, Brian Kirsch wrote:
>
>> From my understanding:
>>
>> 1. Translations and resources will be kept in eggs
>> 2. The Chandler level translations and resource eggs will be on the 
>> sys.path at the very start of Chandler.py
>> 3. At that point it is open for discussion but third party developers 
>> could certainly use the installParcel logic
>>    either in eggs or just as a regular old parcel.
>>
>> I am still a little unclear on number 3.
>
>
> installParcel is entirely unrelated.  Markku's prototype code is 100% 
> Chandler-agnostic.  It doesn't import anything from Chandler, it 
> doesn't do anything with the repository.  It has no idea that there is 
> such a thing as a "parcel".  :)
>
> It doesn't need any of these things because all it does is support 
> eggs publishing their i18n resources, and provide an API for looking 
> up the resources and retrieving them later.  So we can use it in 
> Chandler, and it could be made available for any other project with 
> similar needs.
>
>
> Phillip J. Eby wrote:
>
>>>>>> At 12:51 PM 6/8/2006 -0700, John Anderson wrote:
>>>>>>
>>>>>>> This helps, but I'm still a little confused about one issue. 
>>>>>>> installParcel is called only if the parcel hasn't been loaded, 
>>>>>>> i.e. we don't pay the it's cost every time Chandler is run, only 
>>>>>>> the first time it's run. This turns out to be a big performance 
>>>>>>> win. Can we get the same performance win while 
>>>>>>> loading/registering egg resources?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This approach already does that, by piggybacking on the egg 
>>>>>> scanning that Chandler already does at startup.  installParcel 
>>>>>> and parcel creation happen as a side effect of egg scanning, 
>>>>>> where Chandler notices that there is an egg containing parcels 
>>>>>> that are not in the repository.  This process simply also checks 
>>>>>> for resources in the eggs as it scans them.
>>>>>>
>>>>>>
>>>>>>> Phillip J. Eby wrote:
>>>>>>>
>>>>>>>> At 12:09 PM 6/8/2006 -0700, John Anderson wrote:
>>>>>>>>
>>>>>>>>> I was talking to Markku today and we thought it would be 
>>>>>>>>> useful to have a 4-way Skype conversation to discuss parcel 
>>>>>>>>> loading and egg loading as it related to discovering the 
>>>>>>>>> internationalization files. So, how about meeting via Skype 
>>>>>>>>> tomorrow morning, say 9:30 AM?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In the interest of moving more of this kind of information to 
>>>>>>>> the development lists, I'd just like to go ahead and propose 
>>>>>>>> what I think Chandler should do to load the 
>>>>>>>> internationalization data, using a mechanism based on Markku's 
>>>>>>>> work so far.
>>>>>>>>
>>>>>>>> Markku currently has code (if I understand correctly) that 
>>>>>>>> loops over the eggs on sys.path and builds an index, something 
>>>>>>>> like:
>>>>>>>>
>>>>>>>>     from pkg_resources import working_set
>>>>>>>>
>>>>>>>>     for egg in working_set:
>>>>>>>>         if egg.has_metadata('resource.info'):
>>>>>>>>             # code here to update the registry of resource
>>>>>>>>             # information by reading the 'resource.info' from
>>>>>>>>             # the egg
>>>>>>>>
>>>>>>>> What I would propose doing is to change this code to read instead:
>>>>>>>>
>>>>>>>>     from pkg_resources import working_set, add_activation_listener
>>>>>>>>
>>>>>>>>     @add_activation_listener
>>>>>>>>     def update_resources(egg):
>>>>>>>>         if egg.has_metadata('resource.info'):
>>>>>>>>             # code here to update the registry of resource
>>>>>>>>             # information by reading the 'resource.info' from
>>>>>>>>             # the egg
>>>>>>>>
>>>>>>>> What this code will do, is that whenever an egg is "activated" 
>>>>>>>> (added to sys.path), its resources will be immediately detected 
>>>>>>>> and loaded.
>>>>>>>>
>>>>>>>> Thus, any eggs that are on sys.path when Chandler starts, will 
>>>>>>>> have their resources detected immediately (because 
>>>>>>>> add_activation_listener calls the callback immediately for eggs 
>>>>>>>> that are *already* on sys.path).  Any that are loaded later 
>>>>>>>> (e.g. by the parcel loader scanning PARCELPATH for more eggs) 
>>>>>>>> will automatically cause the resource registry to be updated, 
>>>>>>>> as the egg runtime will call the callback routine as shown above.
>>>>>>>>
>>>>>>>> As a side effect, if we later add the ability to download and 
>>>>>>>> install eggs while Chandler is running, any resources they 
>>>>>>>> define will also be registered.
>>>>>>>>
>>>>>>>> Does this answer the questions that you had in mind for the 
>>>>>>>> meeting, or was there something else you wanted to cover?
>>>>>>>
>>>>>>>
>