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