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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list