> > we aren't really using them for anything
Well, they *should* be used to validate a driver, as was the original intent. If this isn't implemented it would be trivial to add tests for this purpose. It also allows us to automate discovery / validation of drivers rather than manually list them out in some module that needs to be edited each time one is added or removed (which was also an initial intention though meant to be added later on). they can be a little confusing to people who haven't used zope interfaces > elsewhere I think the value-add of both documenting and validating a driver actually eases the development of them, not complicates it. There's not really much you need to know about the package as driver components inherit from available base classes anyway. documenting libcloud with sphinx isn't so automatic when interfaces are > being used A trivial fix; a Sphinx extension for documenting interfaces already exists. See: this ticket<http://bitbucket.org/birkenfeld/sphinx/issue/85/minimal-support-for-zopeinterface>(specifically the finished extension: autointerface_.py <http://bitbucket.org/m//attch/2009/02/autointerface_.py>) I can't argue that now isn't a good time, but I still feel they are (and can be made more) useful. For one, they can assist in getting rid of the * providers.py* file entirely. A simple metaclass which functions as a mount coupled with interface verification (we don't want to provide a driver that doesn't yet implement the API) fixes the need for manually listing / commenting drivers, not to mention the ugly static paths / names that are going on there. Basically, two pretty simple things need to happen to introduce some more usefulness to the interfaces (besides their documentation pluses): - Use verify module as part of the testing process - Get rid of the NotImplementedError methods from the base NodeDriver as this is effectively a competing method of doing the same thing (though one could argue with added ambiguity: "why do I need to implement this?") Obviously I am biased for a couple reasons. One, because I almost always have Twisted available and it handles the interface dependency. And two, because I wrote the interface implementation. Run-time loading of "plugins" along with interface validation is a strategy I'm rather fond of. Not only does it remove the need to maintain a hard-coded list of available modules, it eases implementation. Whenever I happen to forget what a method or attribute is supposed to represent I just consult the interface. The dependency issue should simply be handled in setup.py (if we're using setuptools) or it can be installed easily via pip (or easy_install, if you must). Of course, if everybody else is happy with the way things are now and don't foresee taking advantage of the functionality interfaces can provide, then getting rid of them and porting the documentation to the base classes is always an option. I think it was useful in the beginning just to vet plugins as they were all very new and disparate in their implementation. If everybody is happy manually verifying and exposing drivers (despite it being a far larger pain in the ass, imo) then by all means... Cheers, Tom On Tue, Dec 15, 2009 at 2:43 PM, Jeremy Orem <[email protected]> wrote: > Right now we have a zope interface dependency. I'd like to remove this, > because: > > * we aren't really using them for anything > * they can be a little confusing to people who haven't used zope > interfaces elsewhere > * documenting libcloud with sphinx isn't so automatic when interfaces > are being used > * we haven't made a release, so right now would be a great time to remove > them > > Is anyone opposed to this? > > > Thanks, > > Jeremy >
