I spoke to Chris about this today, and we think we found a way to implement this usefully. The issue that plugin modules are only importable after they have been loaded, so trac.loader needs some additions to take in to account dependencies. Patches should be available in a day or two.
--Noah Kantrowitz (coderanger) On Wednesday 22 March 2006 08:51 pm, Steve Traugott wrote: > Hi All, > > Has anyone ever written a plugin that depends on another plugin? If > so, where did you define the Interface? > > I apologize if I'm missing something obvious, but I can't seem to > figure out the best way to do this, nor find any documentation or > tickets talking about it, fixes in the works, or examples of prior > art. TracDev/ComponentArchitecture talks about components extending > other components, but it doesn't look cleanly doable if those > components are both plugins. I hope I'm wrong; the rest of the > component architecture is so well thought out, it seems suprising that > this would have fallen through the cracks. > > Here's the problem: If fooplugin calls ExtensionPoint(IBar), and > barplugin implements(IBar), then we have to have a sensible place to > define 'class IBar'. I haven't yet found a sensible place: > > - We can define 'class IBar' in barplugin, but that means that > fooplugin has to import IBar from barplugin. This means that > barplugin has to be installed anywhere fooplugin is installed, which > means that when bazplugin gets invented and deprecates barplugin, > barplugin will still have to be installed anyway, because fooplugin > can't load without it. Here's an illustration: > > __________foo.py__________ > from bar import IBar > class Foo(Component): > bars = ExtensionPoint(IBar) > > __________bar.py__________ > class IBar(Interface): > ... > class Bar(Component): > implements(IBar) > > __________baz.py__________ > # created later... replaces Bar, but we can't remove Bar > # because foo.py depends on it > class Baz(Component): > bars = ExtensionPoint(IBar) > > - We can define 'class IBar' in fooplugin, but now we have the same > problem in reverse: barplugin has to import IBar from fooplugin. > This means that fooplugin has to be installed anywhere barplugin is > installed, which means that when bazplugin gets invented and > deprecates fooplugin, fooplugin will still have to be installed > anyway, because barplugin can't load without it. Here's an > illustration: > > __________foo.py__________ > class IBar(Interface): > ... > class Foo(Component): > bars = ExtensionPoint(IBar) > > __________bar.py__________ > from foo import IBar > class Bar(Component): > implements(IBar) > > __________baz.py__________ > # created later... replaces Foo, but we can't remove Foo > # because bar.py depends on it > class Baz(Component): > bars = ExtensionPoint(IBar) > > - We might define 'class IBar' in some dummy plugin whose only purpose > in life is to provide the interface contract, but that just > seems wrong. > > - We might do something clever with Python namespaces, but I haven't > got my mind wrapped around it yet. > > This is all aside from the fact that I haven't been able to get the > above 'import' to work at all if these plugins are installed as eggs > in /var/trac/blah/plugins -- they have to be installed in e.g. > /usr/lib/python2.3/site-packages instead. I don't know enough yet to > know if that is another flaw or just operator error. > > What the heck am I missing? > > Steve _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
