[libvirt] [RFC 0/7] Warn at runtime when deprecated features are used

[Andrea Bolognani]

On Thu, 2018-10-04 at 13:36 +0200, Pavel Hrdina wrote:
> Runtime deprecation warning in C code is wrong in my opinion and even
> though there are some project doing it we should not do it.
> Deprecation warning is for developers, not for users.
> 
> Yes, adding deprecation warning into libvirt will not solve the goal for
> oVirt nor OpenStack, but this should be handled in the libvirt-python
> binding code using language-specific manner as Andrea mentioned above.
> In python it happens to be a runtime warning,
> warnings.DeprecatedWarning, however, that warning is by default ignored
> unless it's triggered from __main__, so developers using libvirt-python
> API would need to enable that warning for their test-suite, that's a
> python way how to do it.
> 
> One of the reasons why it's not enabled by default is that as user
> you have no way how to modify the module code and therefore you should
> not get the warning.  From user point of view everything works how it
> should and I don't care whether my program uses something deprecated 
> or not.  It's unnecessary noise for the user.

All of the above is perfectly reasonable if you only consider cases
where we might want to deprecate an entire API, but fails to take
into account that a large part of libvirt's functionality is exposed
through XML elements and attributes rather than C function calls.

So if we wanted to warn people that not providing a machine type
when defining a guest is a bad idea and they should use libosinfo
to figure out the information instead, there's simply no way we can
do that at compile time.

Not to mention that the existence of virsh somewhat blurs the lines
between users and developers, as it's a very thin wrapper where each
option translates almost directly to the corresponding C function
call and its parameters and flags, but is then installed in $PATH
for the world to use...

> > And for dropping functionality - we can not do that. Period.
> 
> +1, for everyone questioning this please read [1], thanks.
> 
> [1] <https://libvirt.org/support.html>

As mentioned elsewhere, that document defines our current stance on
backwards compatibility, but nothing says we can't change it if we
think doing so will bring benefits to developers and users, which I
strongly believe it would.

We used to have a similar, although not formally documented, stance
on supporting old QEMU versions, but we've since relaxed it[1] which
has benefited libvirt and its developers greatly without, as far as
I'm aware, inconveniencing users.


[1] A change that, I can't help noticing, you signed off on ;)
-- 
Andrea Bolognani / Red Hat / Virtualization