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
