<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 7, 2011, at 12:06 AM, Phil Christensen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Apr 6, 2011, at 8:35 PM, Stephen Thorne wrote:<br><blockquote type="cite">For your consideration, and (constructive) critcism, here is a twisted<br></blockquote><blockquote type="cite">plugin that is nearly identical to 6 that I have running in <br></blockquote><blockquote type="cite">production:<br></blockquote>[snip]<br><blockquote type="cite">serviceMaker = ExampleServiceMaker()<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From these 19 lines of code there are 4 things that are relevent:<br></blockquote><blockquote type="cite">tapname = example<br></blockquote><blockquote type="cite">description = 'Example Twistd Plugin'<br></blockquote><blockquote type="cite">options = {'debug':True} if args == ['--debug'] else {'debug':False}<br></blockquote><blockquote type="cite">service = examplepackage.examplemodule.make_service(**options)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Only 2 of which are relevent for running a twistd daemon other than<br></blockquote><blockquote type="cite">'example'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So the goal of my post to this mailing list is:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* I would like glyph's goal of having less arbitary code executed at<br></blockquote><blockquote type="cite"> twistd launch time to become a realisation,<br></blockquote><br>Makes sense. My first inclination is to suggest creating metadata <br>files that are found via pkg_resources.<br></div></blockquote><div><br></div><div>We already use a similar mechanism, twisted.python.modules, which uses the same underlying standards as pkg_resources (PEP 302) but is somewhat more flexible. And we create a metadata file (dropin.cache) which is stored and retrieved using this mechanism.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">* The entire task of having this python plugin is to link up the<br></blockquote><blockquote type="cite"> metadata with a more or less standard<br></blockquote><br>Not sure if I get this part. I tend to think of plugins as the service <br>bootstrap file, like an int main(). I would probably *not* be into the <br>idea of passing sys.argv directly to a service, for example.<br></div></blockquote><div><br></div><div>Why not? It's just a list of strings. You should be able to deal with it how you like. (But as I said in a previous message: this is a separate issue.)</div><br><blockquote type="cite"><div><blockquote type="cite">* It's very easy to accidentally make your plugin load your package <br></blockquote><blockquote type="cite">for every other twistd daemon running out of the same plugin cache.</blockquote><br>Never had this happen, but I think I can see where it might. It would <br>be solved by some kind of external metadata, though, right?<br></div></blockquote><div><br></div><div>It already is solved by the external metadata... sort of. If you look at the implementation of CachedPlugin, you can see that it actually already has a name and description! There are two problems though: first is that this is hard-coded to be the module's name and docstring, but more importantly, there's just no way to get at those attributes via the getPlugin interface, which implicitly invokes '__conform__' via adaptation (and therefore load()).</div><br><blockquote type="cite"><div>* The practice of putting a module under twisted/plugins/ <br><blockquote type="cite">$mymodulehere.py<br></blockquote><blockquote type="cite"> upsets my equilibrium, the only reason I tolerate this kind of thing<br></blockquote><blockquote type="cite"> is that I install my python code via rpms and I automatically get<br></blockquote><blockquote type="cite"> installation, ownership and uninstallation done in a stable manner.<br></blockquote><br>The only issue I've found with this is the issue of having to create <br>plugin cache files. Apart from the spurious error messages that were <br>(partially?) covered at the sprint recently, the benefit they provide <br>is definitely negated by bad permissions. I've done some acrobatics <br>inside my setup.py to make it work, but it involves different steps <br>depending on whether you're installing or building a package.<br></div></blockquote><div><br></div><div>What is "this kind of thing", though? The plugins have to go in some defined namespace in order to be enumerated. Even if we were to implement something based on purely static metadata, you'd still have to list a directory to get at that metadata. Making the namespace be owned by the module doing the importing makes sense.</div><div><br></div><div>For what it's worth, bzrlib does this too, but by convention in a bzr plugin you put _all_ your code into bzrlib/plugins/foo/*.py, and your package is bzrlib.plugins.foo. (This will work fine with Twisted if you want to do it that way.)</div><br><blockquote type="cite"><div>Still, it seems like most of their necessity would be negated by using <br>external metadata files. It seems to be the way most plugin systems <br>end up going in some way or another.<br></div></blockquote><div><br></div><div>dropin.cache is an external metadata file ;-).</div><br><blockquote type="cite"><div>Anyways, that's just my 2/100ths. I'm pretty happy with most of the <br>plugin model, but I think there's a lot of room for improvement, <br>particularly in the area of dropin.cache files.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>Thanks for your feedback.</div></body></html>