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

[Nicolas Sebrecht]

The 29/08/13, Eric Blake wrote:
> 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'm a bit out of topic but I feel good benefits with the APIs having its
own releases.

Notice I'm talking about the APIs. What makes it hard for small projects
to use the python bindings are the API changes (up to the point that I
don't use them). I guess this issue will stand as long as the APIs keep
highly tied to the python bindings.

In order to get smart backward and forward compatible APIs, I guess it
would make sense to decorelate them from the "low level" bindings.
Introducing a new interface API <-> bindings could do the job of
checking the bindings version and make the correct bindings calls.

Perhaps it would worth the trouble to initiate a new project for such a
"public API"? I think this is another way to solve the issues of this
request, plus the benefits of provinding a very stable public API.

-- 
Nicolas Sebrecht