[Chandler-dev] Meeting Notes: A meeting on python eggs and how they are used in Chandler (with an application to i18n issues)

[John Anderson]

Suggested reading for the meeting:

   * http://peak.telecommunity.com/DevCenter/PythonEggs
   * http://peak.telecommunity.com/DevCenter/setuptools
   * http://peak.telecommunity.com/DevCenter/PkgResources
   * http://peak.telecommunity.com/DevCenter/EasyInstall

Two sample eggs already exist in chandler/projects

We agreed to use Python eggs as the mechanism to deploy language 
translations for Chandler and as the mechanism to distribute Chandler 
parcels.

Python eggs may contain parcels, language translation files, and 
internationalization resources.

There was concern that the overhead of identifying those eggs you are 
working on during development, plus the extra build step required would 
affect developer productivity, especially if large parts of our code 
become egg based.  There is work planned to minimize this overhead.

We agreed to start with the assumption that there will be only one 
gettext Translation Domain per Python egg.

We explored various implementation approaches, most notably the 
following two:

As the Python eggs are discovered during Chandler launch, those that 
contain mo files that have not been copied to the mo installation 
directory will be copied.  So that after Chandler has been started once 
all the mo files are installed. In the long run, when the repository is 
built as part of the build process, our customer would never incur the 
overhead of the step, unless they installed new language eggs, and then 
only once.

The second approach is very similar, except that rather than copying 
files to an installation directory, a dictionary is setup in the 
repository during parcel installation that maps locale to a list of 
paths to each mo file the eggs or some other convenient data structure 
for runtime lookups.

The first approach has the advantage of potentially working with Python 
projects other than Chandler and the gettext mechanism is designed to 
work with mo files stored in a directory.  It has the disadvantage of 
storing two copies of the translation files, and when used by developers 
who regularly create their repository from scratch the translation files 
might not be available before the first string needs to be localized.

The second approach has the advantage of being simpler to implement 
since we can use the existing parcel install mechanism instead of 
building a similar mechanism for eggs. It might also be more efficient 
to use the parcel install mechanism.  It has the disadvantage of 
requiring the gettext lookup to work on a list of files rather than a 
directory of files, and language translations are not available until 
the repository is opened.  This limitation could be eliminated by 
choosing a well-known path for core Chandler translation files which is 
known before the repository is opened.  All the strings that need to be 
translated before the repository is opened would be required to be in 
the core Chandler translation file.

Next Markku and Brian will decide on an implementation plan and 
hopefully we can have a first cut implemented within a week.


Ted Leung wrote:
> Hi,
>
> Please make sure that someone takes good notes during the meeting so 
> that people who don't attend the meeting (and people who have this 
> question in the future) can benefit.
>
> Ted
>
> On May 24, 2006, at 4:54 PM, Markku Mielityinen wrote:
>
>> The concern of this meeting is to bring all attendees up to speed on 
>> how python eggs are going to be used in Chandler. To me at least the 
>> whole concept of python eggs is still not entirely clear and this 
>> makes making good implementation decisions difficult. Hence, I and a 
>> few others have decided to get together to discuss about the subject. 
>> This informal discussion is to be conducted in technical terms and 
>> everyone, like me, will do themselves a favor by taking a few minutes 
>> to browse the list of suggested reading (provided below). Our 
>> application is leaned towards i18n issues but the discussion itself 
>> may still be of interest to others as well - especially those who 
>> work on parcels. Regarding the time and the place for this meeting, 
>> we have not set either but Friday morning and Tuesday next week are 
>> strong candidates. Interested parties should contact me within few 
>> days so that we can fix a time and a place that suits to most us.
>>
>> Suggested reading for the meeting:
>>
>>    * http://peak.telecommunity.com/DevCenter/PythonEggs
>>    * http://peak.telecommunity.com/DevCenter/setuptools
>>    * http://peak.telecommunity.com/DevCenter/PkgResources
>>    * http://peak.telecommunity.com/DevCenter/EasyInstall
>>
>> Cheers,
>>    Markku
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev