[PEAK] PEAK and Eggs

[Phillip J. Eby]

At 09:52 AM 6/12/2006 +0000, Giles Brown wrote:
>>From: "Phillip J. Eby" <pje at telecommunity.com>
>>Yes.  You might look at config.Namespace objects for inspiration, as 
>>something like that could be used to map an entry point group into a 
>>property namespace.
>Ok, here's a bit of a weakness in my understanding.  The uses of Namespace 
>in peak.ini
>all seem to involve using wildcard property names.   Taking for example 
>the use of
>config.Namespace('environ.*'), the nature of these property names is such that
>if I try and iterate them using config.iterKeys() all I get back is the 
>wildcard rule.
>So if I made a section with a (not yet written) EntryPoint() rule looking like
>
>[egg.boxes]
>* = EntryPoints(<some params here>)
>
>how would I list all the egg boxes I had in various egg distributions?

I assumed you were talking about mapping from entry point names to services 
or factories of some kind.  That is, being able to have a property 
namespace like "peak.naming.schemes" that maps to entry points whose names 
are URL schemes.  That use case doesn't require iteration, just 
lookup.  Perhaps you have a different use case in mind.


>Also why would it be better to look at using Namespace() than creating a 
>new type of
>loader (to be registered in "[peak.config.loaders]")?  Or is there a 
>reason I need to do both?

Loaders certainly make more sense if you want iteration.  However, it's not 
clear to me why you wouldn't just iterate over the entry point API directly 
inside some kind of service.  That is, I don't get why you'd want to put it 
in a property namespace and iterate that.  One particular mismatch here is 
that a program could potentially add other eggs/plugins at runtime, thus 
expanding the available entry points.  But property namespaces are frozen 
once you read them, and iterating over a property namespace prevents any 
new entries from being added after that point.