incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Davis <...@dislocatedday.com>
Subject Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Date Wed, 16 Dec 2009 19:57:52 GMT
On the subject of loading and metaclasses, it's very simple to do something
like:


class DriverMount(type):
    def __init__(cls, name, bases, attrs):
        if not hasattr(cls, 'drivers'):
            cls.drivers = []
        else:
            cls.drivers.append(cls)

class BaseDriver(object):
    __mnetaclass__ = DriverMount


Now any time you subclass from BaseDriver you get added to
BaseDriver.drivers. The rest you can imagine for yourself. Obviously this
requires that all modules be imported, but libcloud is hardly large enough
for that to be of concern (IMO).

ANYWAY. The implementation of this isn't really the point of this discussion
(and I'm not particularly passionate about it either way; I just prefer to
remove as many manual steps / assumptions as possible in general). I think
Alex put it pretty well:

While I love the idea of interfaces, I'm not 100% sold it is that big of a
> win over just solid, well documented, base classes coupled with a good test
> suite.  It was great when we had *no* structure... but now we have a solid
> set of base classes which seem to be working well.


In the beginning I fought to retain interfaces because I felt they were
necessary at the time. I think we have enough existing drivers and stability
at this point for that not to be the case. It *does* remove a dependency
that many may not have normally and I concede that many people don't have a
lot of experience with interface or Zope stuff in general. I happen to like
a lot of ideas in the Zope and Twisted ecosystems but at the end of the day
my only desire is to do whatever is best for the project.

The fact that the interfaces can be removed without impacting much of
anything aside from a test or two indicates that they aren't being used to
their full potential. In the case of this project, that's probably not a bad
thing; it isn't terribly complicated from an interface point of view and
only has a few object types to corral. Initially I was expecting things to
be far more complicated quickly but the focus has stayed on providing basic
support through existing APIs and libraries for as many providers as
possible, which is a choice I support.

On Wed, Dec 16, 2009 at 12:17 PM, Ian Bicking <ianbicking@gmail.com> wrote:

> On Wed, Dec 16, 2009 at 11:08 AM, Jed Smith <jed@jedsmith.org> wrote:
>
> > On Dec 15, 2009, at 6:17 PM, Ian Bicking wrote:
> >
> > > I don't understand how a metaclass would help here?  I'm assuming that
> > > lazily loading modules is a requirement here (i.e., you shouldn't have
> > the
> > > Slicehost module loaded unless you are using Slicehost).
> >
> > I hope that's not the driving rationale, and if it is I'll return to the
> > gain-for-effort ratio; what's the advantage of lazy loading for a library
> > the size of libcloud?
> >
>
> The alternative to lazy loading isn't awesome either.  It means you have
> some module that does:
>
> from libcloud.drivers import ec2
> from libcloud.drivers import linode
> from libcloud.drivers import rackspace
> from libcloud.drivers import slicehost
> ...
>
> That's not exactly awesome.  But then each module can register itself.
>  Heck, you could just put a classmethod on the base class for Driver,
> .register(), that looks like:
>
>    @classmethod
>    def register(cls):
>        global_driver_registry[cls.name] = cls
>
> And just be sure to call SpecificDriver.register().  But eh.
>
> Also, potentially libcloud drivers could be based on other code, for
> instance if there's a vendor-supported library, and the driver just adapts
> that API to libcloud's.  That vendor-supported library might be largish,
> and
> you'd be importing it (and requiring that it be available) regardless of
> whether it is used.
>
>
> --
> Ian Bicking  |  http://blog.ianbicking.org  |
> http://topplabs.org/civichacker
>

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