You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Jeremy Orem <or...@oremj.com> on 2009/12/15 20:43:43 UTC
[libcloud] Proposal: remove zope interfaces from libcloud.
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
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Jed Smith <je...@jedsmith.org>.
On Dec 15, 2009, at 4:11 PM, Tom Davis wrote:
>> 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).
Since providers are added every now and then instead of every day, I think
manually specifying which providers are included is not that big of a deal.
As for autodiscovery of drivers within each provider, that is what subclasses
and introspection are for -- introducing an entire abstraction layer with
Zope is not the best solution for this task.
If I were designing such a system from scratch, it'd look something like:
base.py:
class Driver(object):
pass
providerA.py:
import base
class ProviderADriver1(base.Driver):
def hello(self):
print "Hello from driver 1 in provider A!"
class ProviderADriver2(base.Driver):
def hello(self):
print "Hello from driver 2 in provider A!"
class UnrelatedObject(object):
def hello(self):
print "Oh noes :("
providers.py:
import providerA
loading_crap.py:
import base
import providers
def toplevel(mod):
for i in dir(mod):
if i[:2] != "__":
yield i
def interested(mod, obj):
try:
item = eval("providers.%s.%s" % (mod, obj))
return item if issubclass(item, base.Driver) else None
except: return None
def main():
drivers = []
for prov in toplevel(providers):
possible = toplevel(eval("providers.%s" % prov))
drivers.extend(interested(prov, i) for i in possible)
for driver in drivers:
if not driver:
continue
else:
d = driver()
d.hello()
if __name__ == "__main__":
main()
11:40 jsmith@upsidedown% python loading_crap.py
Hello from driver 1 in provider A!
Hello from driver 2 in provider A!
Very rough, but I've taken this approach with my software in the past. This
is the real lazy approach, even -- more maintainable and less prone to
programmer error is to have a specific member that the loader code looks for,
which enumerates the drivers the plugin expects the loader to load.
Python's introspection capabilities make it shine in this regard, allowing
really easy stuff which took me weeks in .NET -- I just wrote that example
above in about 20 minutes. You don't need a heavyweight import like Zope to
get that done, and the arguments I'm reading in this thread for documentation
and testing just aren't selling me on it.
Plus, look how easy providerA's interface was to write.
> 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.
That would introduce a hurt locker full of complexity for little to no gain.
Static things in code, particularly just a list of providers that the library
supports, are nothing to be afraid of and are far from ugly.
How satisfying is it to a committer to see their work's name added to "the
list"? That's almost a signature of we-accept-this-module. Since libcloud
is a product which is, for the most part, centrally-controlled, a lot of the
automated discovery stuff is for no benefit whatsoever as /we/ are in control
of what goes out in the repository. Developers making a module can add their
own, and that's not terribly difficult -- having libcloud automagically say
"hey! I see your new provider and plugins within!" is a novelty, at best,
for an extraordinarily small use case.
Honestly, and perhaps a little off-topic, I haven't liked Zope since the
beginning of time because some of the approaches they take with Python really
go against, in my mind, what Python is all about. Python was designed with a
lack of interfaces on purpose, and munging them isn't helping things.
(However, I am biased toward Django -- which performs unspeakable horrors...)
> 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...
I disagree that it's a larger pain in the ass. Pulling such a heavyweight
dependency in via setuptools or forcing people to install it just to use the
product is the pain in the ass to me; if it did my dishes I might consider it,
but the amount of gain awarded is disproportionate to the effort put in.
JS
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Ian Bicking <ia...@gmail.com>.
On Tue, Dec 15, 2009 at 4:44 PM, Paul Querna <pa...@querna.org> wrote:
> > Second, you could have a simple reflection API, like:
> >
> > def drivers():
> > """Returns a list of drivers (by name)"""
> > return [
> > os.path.splitext(name)[0]
> > for name in os.listdir(os.path.join(os.path.dirname(__file__),
> > 'drivers')))
> > if name.endswith('.py') and name != '__init__.py']
>
>
> Would this interface work on google app engine or similiar
> enviroments? I ddin't think things like os.listdir etc would be
> expected to work?
>
It will work fine; you can read files on app engine, you just can't write
them. Any environment that supports templates will support these kind of
operations, as templates are often shipped similar to this.
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Tom Davis <to...@dislocatedday.com>.
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 <ia...@gmail.com> wrote:
> On Wed, Dec 16, 2009 at 11:08 AM, Jed Smith <je...@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
>
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Ian Bicking <ia...@gmail.com>.
On Wed, Dec 16, 2009 at 11:08 AM, Jed Smith <je...@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
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Jed Smith <je...@jedsmith.org>.
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?
JS
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Ian Bicking <ia...@gmail.com>.
On Tue, Dec 15, 2009 at 4:53 PM, Tom Davis <to...@dislocatedday.com> wrote:
> Yeah, I would never rely on the likes of directory sniffing. You're also
> making the assumption that anything in the drivers directory contains a
> driver, the connection class is named a certain way, etc.
If this API is in libcloud, those assumptions will be enforced -- if someone
puts code that doesn't work with that expectation, it'll break and someone
will have to fix it.
> It's full of too
> many holes. Throwing out the subject of interfaces entirely, this is still
> much more reliably achieved by a metaclass.
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). So... without
loading the module there's a limit to what you can do.
There are other techniques for loading plugins like this, but I find they
lead to unnecessary overhead and indirection (e.g., egg entry points).
There are perhaps a couple lighter ways that would be possible. E.g.,
drivers (that don't ship with libcloud) could install a .pth file like:
import libcloud_driver_registry; libcloud_driver_registry.register('driver
name', 'module_name')
And then libcloud_driver_registry would be a really small module that just
accepts these registrations. This is if you have drivers located in
third-party packages. With eggs you'd have an entry point, and do
pkg_resources.list_entry_points('libcloud.drivers'). Which... actually
isn't so bad, but the first time you call that all entry points for all
libraries get parsed. But if you support direct import, that overhead will
only be incurred for code that wants to see the available drivers. So...
entry points are reasonable.
One thing I forgot to mention about my example code is it doesn't work with
zipped packages. You can declare libcloud as being zip-unfriendly, or you
can use some fancier APIs that abstract out listdir etc (they are in
pkg_resources somewhere).
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Tom Davis <to...@dislocatedday.com>.
Yeah, I would never rely on the likes of directory sniffing. You're also
making the assumption that anything in the drivers directory contains a
driver, the connection class is named a certain way, etc. It's full of too
many holes. Throwing out the subject of interfaces entirely, this is still
much more reliably achieved by a metaclass.
On Tue, Dec 15, 2009 at 5:44 PM, Paul Querna <pa...@querna.org> wrote:
> On Tue, Dec 15, 2009 at 1:41 PM, Ian Bicking <ia...@gmail.com> wrote:
> > On Tue, Dec 15, 2009 at 3:11 PM, Tom Davis <to...@dislocatedday.com>
> wrote:
> >> 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.
> >
> > This seems like it can be resolved anyway, and interfaces don't seem
> > like a particularly easy easy way to solve the problem.
> >
> > First, you could just import the drivers directly instead of the
> > get_driver indirection. The only thing get_driver gives you is the
> > ability to lazy-load something based on fixed symbols.
> >
> > Second, you could have a simple reflection API, like:
> >
> > def drivers():
> > """Returns a list of drivers (by name)"""
> > return [
> > os.path.splitext(name)[0]
> > for name in os.listdir(os.path.join(os.path.dirname(__file__),
> > 'drivers')))
> > if name.endswith('.py') and name != '__init__.py']
>
>
> Would this interface work on google app engine or similiar
> enviroments? I ddin't think things like os.listdir etc would be
> expected to work?
>
> Thanks,
>
> Paul
>
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 15, 2009 at 1:41 PM, Ian Bicking <ia...@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 3:11 PM, Tom Davis <to...@dislocatedday.com> wrote:
>> 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.
>
> This seems like it can be resolved anyway, and interfaces don't seem
> like a particularly easy easy way to solve the problem.
>
> First, you could just import the drivers directly instead of the
> get_driver indirection. The only thing get_driver gives you is the
> ability to lazy-load something based on fixed symbols.
>
> Second, you could have a simple reflection API, like:
>
> def drivers():
> """Returns a list of drivers (by name)"""
> return [
> os.path.splitext(name)[0]
> for name in os.listdir(os.path.join(os.path.dirname(__file__),
> 'drivers')))
> if name.endswith('.py') and name != '__init__.py']
Would this interface work on google app engine or similiar
enviroments? I ddin't think things like os.listdir etc would be
expected to work?
Thanks,
Paul
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Ian Bicking <ia...@gmail.com>.
On Tue, Dec 15, 2009 at 3:11 PM, Tom Davis <to...@dislocatedday.com> wrote:
> 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.
This seems like it can be resolved anyway, and interfaces don't seem
like a particularly easy easy way to solve the problem.
First, you could just import the drivers directly instead of the
get_driver indirection. The only thing get_driver gives you is the
ability to lazy-load something based on fixed symbols.
Second, you could have a simple reflection API, like:
def drivers():
"""Returns a list of drivers (by name)"""
return [
os.path.splitext(name)[0]
for name in os.listdir(os.path.join(os.path.dirname(__file__),
'drivers')))
if name.endswith('.py') and name != '__init__.py']
def load_driver(name):
mod_name = 'libcloud.drivers.%s'
__import__(mod_name)
mod = sys.modules[mod_name]
return getattr(mod, name.capitalize()+'Connection')
This is easier to use than the current setup, and less code to boot.
> 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.
A good abstract base class solves this, I think. API verification
doesn't seem like a big win, as that's the most trivial of bugs
(simply forgetting to implement something), and all the important bugs
are when implementations are wrong, not missing. If there are
easy-to-miss corners of the API, you can still write tests using
hasattr, like:
for method in ['host', 'request', ...]:
assert hasattr(driver, method) and getattr(driver, method) is not
getattr(ConnectionUserAndKey, method)
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Alex Polvi <po...@cloudkick.com>.
On Tue, Dec 15, 2009 at 1:11 PM, Tom Davis <to...@dislocatedday.com> wrote:
>>
>> we aren't really using them for anything
>
>
> Well, they *should* be used to validate a driver, as was the original
> intent.
We use verifyObject a bunch:
https://svn.apache.org/repos/asf/incubator/libcloud/trunk/test/test_base.py
I have not found it that useful. It only seems to check that it has
the "implements(IBlah)" clause and does not actually do any sort of
internal object introspection. Maybe I am using it wrong, but it seems
like testing the interfaces with normal unit tests would do the same
thing.
> 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).
How would auto discovery work with zope?
> I think the value-add of both documenting and validating a driver actually
> eases the development of them, not complicates it.
I feel like we could just document the base class. The testing stuff,
as mentioned above, does not seem to be that big of a win.
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.
-Alex
> On Tue, Dec 15, 2009 at 2:43 PM, Jeremy Orem <or...@oremj.com> 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
>>
>
--
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Tom Davis <to...@dislocatedday.com>.
>
> 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 <or...@oremj.com> 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
>
Re: [libcloud] Proposal: remove zope interfaces from libcloud.
Posted by Jed Smith <je...@jedsmith.org>.
On Dec 15, 2009, at 2:43 PM, Jeremy Orem wrote:
> Is anyone opposed to this?
I support it, as just getting Zope to install into a development environment
under Debian took much pain and suffering. It's a lot of trouble for little
gain, in my opinion.
Debuntu's packaging system is pretty smart in this regard, but I could
foresee a packager for another distribution pulling in all of Zope as a
dependency just for libcloud.
JS