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?
Jirka