Re: [libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least

2017-09-14 Thread Michal Privoznik 
On 09/14/2017 02:42 PM, Daniel P. Berrange wrote:
> On Thu, Sep 14, 2017 at 01:41:08PM +0200, Michal Privoznik wrote:
>> Currently, we require 0.9.11. However, some APIs are missing
>> there and thus sanity check fails:
>>
>> DEBUG: /usr/bin/python sanitytest.py build/lib.linux-s390x-2.7 
>> /usr/share/libvirt/api/libvirt-api.xml
>> DEBUG: FAIL virStream.sparseRecvAll   (Python API not mapped to C)
>> DEBUG: FAIL virStream.sparseSendAll   (Python API not mapped to C)
>> DEBUG: error: command '/usr/bin/python' failed with exit status 1
>>
>> I'm not sure how to fix that so raising minimal required libvirt
>> version is the solution.
>>
>> Signed-off-by: Michal Privoznik 
>> ---
>>  setup.py   |   2 +-
>>  README |   2 +-
>>  libvirt-override.c | 149 
>> -
>>  3 files changed, 2 insertions(+), 151 deletions(-)
>>
>> diff --git a/setup.py b/setup.py
>> index f33ff1a..f929eb2 100755
>> --- a/setup.py
>> +++ b/setup.py
>> @@ -17,7 +17,7 @@ import re
>>  import shutil
>>  import time
>>  
>> -MIN_LIBVIRT = "0.9.11"
>> +MIN_LIBVIRT = "3.4.0"
> 
> NACK, we cannot do this - it will break many people and apps (OpenStack
> in particular) who expect latest libvirt on pypi to work with historical
> C libs.

I don't know how pypi works, but if somebody distributes just
libvirt-python and doesn't ship libvirt.so too, such process is broken
already because libvirt-python could have been compiled with one version
of libvirt while user might be running a different one. So shipping
libvirt.so is the only way. And since libvirt-python doesn't add any new
features compared to bare libvirt, why on earth would somebody want to
run latest libvirt-python but an ancient libvirt? It doesn't make much
sense to update one without other.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least

2017-09-14 Thread Daniel P. Berrange 
On Thu, Sep 14, 2017 at 03:05:15PM +0200, Michal Privoznik wrote:
> On 09/14/2017 02:42 PM, Daniel P. Berrange wrote:
> > On Thu, Sep 14, 2017 at 01:41:08PM +0200, Michal Privoznik wrote:
> >> Currently, we require 0.9.11. However, some APIs are missing
> >> there and thus sanity check fails:
> >>
> >> DEBUG: /usr/bin/python sanitytest.py build/lib.linux-s390x-2.7 
> >> /usr/share/libvirt/api/libvirt-api.xml
> >> DEBUG: FAIL virStream.sparseRecvAll   (Python API not mapped to C)
> >> DEBUG: FAIL virStream.sparseSendAll   (Python API not mapped to C)
> >> DEBUG: error: command '/usr/bin/python' failed with exit status 1
> >>
> >> I'm not sure how to fix that so raising minimal required libvirt
> >> version is the solution.
> >>
> >> Signed-off-by: Michal Privoznik 
> >> ---
> >>  setup.py   |   2 +-
> >>  README |   2 +-
> >>  libvirt-override.c | 149 
> >> -
> >>  3 files changed, 2 insertions(+), 151 deletions(-)
> >>
> >> diff --git a/setup.py b/setup.py
> >> index f33ff1a..f929eb2 100755
> >> --- a/setup.py
> >> +++ b/setup.py
> >> @@ -17,7 +17,7 @@ import re
> >>  import shutil
> >>  import time
> >>  
> >> -MIN_LIBVIRT = "0.9.11"
> >> +MIN_LIBVIRT = "3.4.0"
> > 
> > NACK, we cannot do this - it will break many people and apps (OpenStack
> > in particular) who expect latest libvirt on pypi to work with historical
> > C libs.
> 
> I don't know how pypi works, but if somebody distributes just
> libvirt-python and doesn't ship libvirt.so too, such process is broken
> already because libvirt-python could have been compiled with one version
> of libvirt while user might be running a different one. So shipping
> libvirt.so is the only way. And since libvirt-python doesn't add any new
> features compared to bare libvirt, why on earth would somebody want to
> run latest libvirt-python but an ancient libvirt? It doesn't make much
> sense to update one without other.

Pypi only ships the source tar.gz. When you pip install libvirt-python
it is then built against the libvirt C library you have installed. The
newer libvirt-python bindings sometimes fix bugs wrt bindings of previously
existing APIs, so there is a reason to run newer libvirt-python. In addition
building libvirt-python from pypi instead of relying on distro installed
RPMs of libvirt-python lets apps use arbitrary versions of python, not just
the one the distro built against. This all works very well and is relied
upon by OpenStack.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least

2017-09-14 Thread Martin Kletzander 

On Thu, Sep 14, 2017 at 01:41:08PM +0200, Michal Privoznik wrote:

Currently, we require 0.9.11. However, some APIs are missing
there and thus sanity check fails:

DEBUG: /usr/bin/python sanitytest.py build/lib.linux-s390x-2.7 
/usr/share/libvirt/api/libvirt-api.xml
DEBUG: FAIL virStream.sparseRecvAll   (Python API not mapped to C)
DEBUG: FAIL virStream.sparseSendAll   (Python API not mapped to C)
DEBUG: error: command '/usr/bin/python' failed with exit status 1

I'm not sure how to fix that so raising minimal required libvirt
version is the solution.



I think the whole point is to be able to compile with any older (sane)
version of libvirt, so you should *not* do this.  We already have a
mechanism for this, it's just that the naming of these functions doesn't
fit it and it needs to be adjusted IIRC.  See function shouldSkip() in
generator.py.

From me this is NACK until convinced otherwise.


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt-python][PATCH] maint: Require libvirt-3.4.0 at least

2017-09-14 Thread Daniel P. Berrange 
On Thu, Sep 14, 2017 at 01:41:08PM +0200, Michal Privoznik wrote:
> Currently, we require 0.9.11. However, some APIs are missing
> there and thus sanity check fails:
> 
> DEBUG: /usr/bin/python sanitytest.py build/lib.linux-s390x-2.7 
> /usr/share/libvirt/api/libvirt-api.xml
> DEBUG: FAIL virStream.sparseRecvAll   (Python API not mapped to C)
> DEBUG: FAIL virStream.sparseSendAll   (Python API not mapped to C)
> DEBUG: error: command '/usr/bin/python' failed with exit status 1
> 
> I'm not sure how to fix that so raising minimal required libvirt
> version is the solution.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  setup.py   |   2 +-
>  README |   2 +-
>  libvirt-override.c | 149 
> -
>  3 files changed, 2 insertions(+), 151 deletions(-)
> 
> diff --git a/setup.py b/setup.py
> index f33ff1a..f929eb2 100755
> --- a/setup.py
> +++ b/setup.py
> @@ -17,7 +17,7 @@ import re
>  import shutil
>  import time
>  
> -MIN_LIBVIRT = "0.9.11"
> +MIN_LIBVIRT = "3.4.0"

NACK, we cannot do this - it will break many people and apps (OpenStack
in particular) who expect latest libvirt on pypi to work with historical
C libs.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list