On 1/19/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > There's a couple options then: > > 1. Later a new entry point is created for the new interface. E.g., > 'python.templating.engines2'.
I'd rather not start sticking version numbers on entry points. If anything, I'd rather start down the path of having a small project that represents the interface (possibly with a base class) so that plugins can require a specific version of that project to reflect which version of the interface they work with. > 2. The spec is changed immediately to allow arbitrary keywords, and > plugins are expected to ignore keywords they don't understand. Later > keywords can be added to control aspects, hopefully with reasonable > compatibility. For instance, it is not horrible if a template plugin > ignores the search path (confusing, maybe). I can get behind this one. I'd be interested in hearing Christian's perspective. (There are also 3 other people, all on this list I believe, that have written plugins.) > 3. The plugin instances grow a new method like "set_search_path()". > Consumers should check for the existance of this method, and call it if > necessary. It seems like the more pythonic thing to do is just say plugin.search_path = [...]. If a given plugin needs behavior to go with that, it can implement a property. A framework using the plugins can set the search_path and the plugin can decide whether or not to use it. This is my favorite choice. It's completely compatible and pretty reasonable. #2 is just a little more concise. > > 4. We standardize the meaning of an option. This is not unlike 2, > except doesn't require any changes to anything. That makes it easy. > Options are no longer completely template-specific. > > 5. We add the option right now, but some plugins may ignore it (but > they'll have to update their signatures). > > Maybe 4 is easiest, but with it and some of the others you might get > developer confusion when the path isn't respected (and it'll be the > frustrating why-doesn't-anything-I-do-effect-the-output kind of problem). I like #3 the best. It's compatible and it's also an easy way to grow the interface moving forward. Kevin
