On Mon, Feb 21, 2022 at 05:28:24PM +0100, Wim de With wrote:
On Mon, Feb 21, 2022 at 10:21:32AM -0500, Andrea Bolognani wrote:
> 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.
I realized that GitLab is nowadays used for communication so I made more
specific issues there. Do you prefer merge requests there or patches on
the mailing list?
Merge requests exclusively for anything other than libvirt.git
> 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.
I've done some experiments here with bindgen, and it is pretty
straightforward to generate FFI bindings using it. The problem is that
generating safe idiomatic Rust wrappers on top of these bindings is
non-trivial. Still, most wrapper functions will probably follow the same
pattern, so it may be useful to investigate if macros could be used to
make it easier to add new functions.
>From looking at the Git diff from v2.5.0 to v8.0.0, the libvirt API
doesn't seem to change that often. Almost all changes consist of adding
new enum variants and some new functions. Am I correct in assuming that
an application that was written for v2.5.0 would still work with v8.0.0?
Correct, libvirt never knowingly breaks API compatibility. The API
is strictly append-only.
To me it seems the best course of action would be to pick some
minimum
version of libvirt to support, and make sure that the Rust API wraps all
functions there. From that point, adding functions and enum variants
introduced in later versions of libvirt can be incremental changes and
will (hopefully) be fairly easy to add. Rust has the concept of features
to enable conditional compiling of those functions and enum variants
only when the underlying libvirt supports them.
Conditional compilation is what we do in Go / Python bindings too.
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 :|