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

[Daniel P. Berrange]

On Fri, Aug 30, 2013 at 09:44:26AM +0200, Michal Privoznik wrote:
> On 29.08.2013 13:24, Daniel P. Berrange wrote:
> > As everyone knows, we have historically always shipped the python binding
> > as part of the libvirt primary tar.gz distribution. In some ways that has
> > simplified life for people, since we know they'll always have a libvirt
> > python that matches their libvirt C library.
> > 
> > At the same time though, this policy of ours is causing increasing amounts
> > of pain for a number of our downstream users.
> > 
> > In OpenStack, in particular, their development and test environments aim
> > to be able to not rely on any system installed python packages. They use
> > a virtualenv and pip to install all python deps from PyPi (equivalent of
> > Perl's CPAN in Python world). This approach works for everything except
> > the libvirt Python code which is not available standalone on PyPi. This
> > is causing so much pain that people have suggested taking the libvirt
> > python code we ship and just uploading it to PyPi themselves[1]. This
> > would obviously be a somewhat hostile action to take, but the way we
> > distribute libvirt python is forcing OpenStack to consider such things.
> > 
> > In RHEL world too, bundling of libvirt + its python binding is causing
> > pain with the fairly recent concept of "software collections"[2]. This
> > allows users to install multiple versions of languages like Python, Perl,
> > etc on the same box in parallel. To use libvirt python with thse alternate
> > python installs though, requires that they recompile the entire libvirt
> > distribution just to get the Python binding. This is obviously not an
> > approach that works for most people, particularly if they're looking to
> > populate their software collection using 'pip' rather than RPM.
> > 
> > Looking on google there are a number of other people asking for libvirt
> > python as a separate module, eg on Stackoverflow[3].
> 
> I am not sure about PyPi (I'm not an intense python user), but I think
> you are mixing two problems here. One is having some bindings in the git
> repo the other is packaging. If we are not shipping python bindings in a
> separate package (like we do for qemu for instance) or the -python
> package is not optional, then this is the problem.
> 
> Personally, I think if we do this, then python bindings will suffer from
> the decision every time somebody introduces an API extension. Because
> sooner or later we will forget to update the python bindings.

If we address this via automated testing though, I think the problem of
keeping them in sync pretty much goes away.  The generator will handle
most additions, and we'd get notification of build problems in cases
where it didn't handle them.

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 :|