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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
