libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <ianbick...@gmail.com>
Subject Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Date Wed, 16 Dec 2009 17:17:24 GMT
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