Re: Libvirt Rust bindings could use some work
On Fri, Feb 18, 2022 at 10:28:29AM +0100, Wim de With wrote:
Hello,
I was reading the Rust bindings for libvirt and I noticed that they are
not very idiomatic. A couple of examples:
1. It is conventional to have a *-sys crate containing only the C
interface and the linking configuration. The virt crate would then
depend on this libvirt-sys crate to implement a safe and ergonomic
wrapper.
2. The API heavily uses integers to indicate flags. Sometimes those
integers are type aliased and sometimes they are not. In Rust, this can
be much nicer, using enums to represent only valid flags. The same
applies to some return values.
3. Since libvirt is thread-safe, the Rust types could be Send and Sync,
so that they can also be used in a multithreaded context. Special care
needs to be taken with translating virGetLastError to Rust Results, but
it shouldn't be a problem.
For a nice example of a Rust wrapper around a C library, see:
https://github.com/rust-lang/git2-rs
I am willing to send some patches to fix some of these problems, but
this will almost certainly lead to breaking API changes, and I am not
sure what your opinion is on that.
We are aware of the issues with the current API of libvirt-rs, but
unfortunately nobody has been able to dedicate time to addressing
them. Any contributions towards that goal that you or anyone else
could make would certainly be greatly appreciated!
Breaking the API should be fine I think. The current version number
is 0.2.11, so there shouldn't be any expectation in terms of API
stability.
Note that libvirt-python is mostly autogenerated, and there is an
ongoing effort to make the same happen for libvirt-go-module. Ideally
libvirt-rust would also follow this trend and end up with very little
manually-written code in it.
Finally, while I am not a legal expert, I believe that licensing a
Rust
library as LGPL does not make much sense. Rust does not have a stable
ABI so everything is statically linked. This means that adding virt to a
Cargo.toml file of a non-GPL application is already in violation of the
license.
Licensing is a pretty fun minefield :)
For example, even though libvirt-rs itself would be statically linked
into any application that uses it, by virtue of it being a wrapper
around the C library you'd still end up dynamically linking against
that.
I tend to agree that language bindings should follow the rest of the
language ecosystem in terms of licensing, and for libvirt-rs
specifically that would probably mean MIT. Perhaps we should consider
looking into relicensing the project?
--
Andrea Bolognani / Red Hat / Virtualization