On Wed, Aug 13, 2014 at 04:24:57PM +0100, Mark McLoughlin wrote: > On Wed, 2014-08-13 at 10:26 +0100, Daniel P. Berrange wrote: > > On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote: > > > On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote: > > > > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote: > > > > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote: > > > > > > While forcing people to move to a newer version of libvirt is > > > > > > doable on most environments, do we want to do that now? What is > > > > > > the benefit of doing so? > > > > > [...] > > > > > > > > > > The only dog I have in this fight is that using the split-out > > > > > libvirt-python on PyPI means we finally get to run Nova unit tests > > > > > in virtualenvs which aren't built with system-site-packages enabled. > > > > > It's been a long-running headache which I'd like to see eradicated > > > > > everywhere we can. I understand though if we have to go about it > > > > > more slowly, I'm just excited to see it finally within our grasp. > > > > > -- > > > > > Jeremy Stanley > > > > > > > > > We aren't quite forcing people to move to newer versions. Only those > > > > installing nova test-requirements need newer libvirt. > > > > > > Yeah, I'm a bit confused about the problem here. Is it that people want > > > to satisfy test-requirements through packages rather than using a > > > virtualenv? > > > > > > (i.e. if people just use virtualenvs for unit tests, there's no problem > > > right?) > > > > > > If so, is it possible/easy to create new, alternate packages of the > > > libvirt python bindings (from PyPI) on their own separately from the > > > libvirt.so and libvirtd packages? > > > > The libvirt python API is (mostly) automatically generated from a > > description of the XML that is built from the C source files. In > > tree with have fakelibvirt which is a semi-crappy attempt to provide > > a pure python libvirt client API with the same signature. IIUC, what > > you are saying is that we should get a better fakelibvirt that is > > truely identical with same API coverage /signatures as real libvirt ? > > No, I'm saying that people are installing packaged versions of recent > releases of python libraries. But they're skeptical about upgrading > their libvirt packages. With the work done to enable libvirt be uploaded > to PyPI, can't the two be decoupled? Can't we have packaged versions of > the recent python bindings on PyPI that are independent of the base > packages containing libvirt.so and libvirtd?
It is already de-coupled - the libvirt-python module up on PyPI is capable of building against any libvirt.so C library version 0.9.11 -> $CURRENT. The problem with Ubuntu precise is that it is C library version 0.9.6 which we can't build against because that vintage libvirt never installed the libvirt-api.xml file that we use to auto-generated the python code from. 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 :| _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev