[libvirt] RFC: Splitting python binding out into a separate repo & ading to PyPi

[Daniel P. Berrange]

On Thu, Aug 29, 2013 at 02:50:22PM +0200, Jiri Denemark wrote:
> On Thu, Aug 29, 2013 at 12:24:41 +0100, Daniel Berrange wrote:
> ...
> > IMHO we should / must listen to our users here before it is too late.
> > 
> > We can still release libvirt python at the same time as normal libvirt
> > releases, and require that people update the bindings whenever adding
> > new APIs (if the generator doesn't cope with them). We should simply
> > distribute python as a separate tar.gz, as we do for all other languages,
> > and upload it to PyPi, as well as libvirt.org FTP when doing a release.
> > 
> > Obviously there will be some work to separate things out, but I don't
> > see that being insurmountable, since all other language bindings manage
> > to be separate, even when doing code generation. We'd also want to
> > change to use distutils, rather than autoconf, since that's what the
> > python world wants.
> 
> Your suggestion looks reasonable from the python community point of
> view. However, the main benefit in having python bindings in the same
> repo with libvirt itself is that it's always (for a bit relaxed
> definition of always) in sync with libvirt. In case we split it, I'd
> like us to do it in a way that anyone hacking libvirt will also
> automatically get and build python bindings. Is git submodule something
> that could help with that? Or is this a complete nonsense?

To be honest, I don't really see why the python binding needs to be
treated as a special case amongst all our language bindings, other
than due to the historical accident that DV put them in tree when
writing libvirt.

With the Perl bindings I have a test case which analyses the libvirt-api.xml
file and the symbols referenced by the binding code. It then reports on any
APIs which have not be mapped to the Perl. Likewise for header file
constants. If we wrote a similar test case for the python, and then had an
automated build we'd quickly detect any case where we added a new API that
was not automatically handled by the python generator.py


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|