incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Davis <>
Subject Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Date Tue, 15 Dec 2009 21:11:56 GMT
> 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<>(specifically
the finished extension: <>)

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 ** 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 (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...



On Tue, Dec 15, 2009 at 2:43 PM, Jeremy Orem <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message