On 08/29/2013 05:24 AM, Daniel P. Berrange wrote:
I don't think these issues are going to go away, in fact I think they
will likely become more pressing, until the point where some 3rd party
takes the step of providing libvirt python bindings themselves. I don't
think we want to let ourselves drift into the situation where we loose
control over releasing libvirt python bindings.
Splitting the python bindings into their own project makes sense to me.
We've got enough interest in python on this list that I'm not too
worried about enforcing that new APIs to the main project be accompanied
with patches to libvirt-python.git, and keep up with a release of the
bindings for each upstream release.
I don't think the python bindings should be a submodule of libvirt
proper, but I wouldn't be opposed to a meta-git project that has both
libvirt, libvirt-python, and possibly other libvirt-* binding
subprojects as submodules, so that you could update the metaproject and
pick up all the bindings at once.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org