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

[Andi Vajda]

On Thu, 8 Jun 2006, Brian Kirsch wrote:

> 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.

+1

Andi..

>
> -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?
>>>>>>>> 
>>>>>>>> 
>> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>