On Thu, Oct 04, 2018 at 02:06:54PM +0200, Andrea Bolognani wrote: > 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. Sure, if we want to warn about missing/wrong/deprecated features from XML we need runtime warnings only for that and that's OK, that is something that user usually can change. > 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... Again if it's something XML related user can change that even while using virsh, if it's API related user should not see it by default. > > > 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. I'm not sure whether we had that promise for QEMU versions documented and it's also slightly different situation. We are dropping support for old QEMUs in new libvirts with the assumption that user usually updates both at the same time (through OS distribution channels). Removing APIs is totally different. We would have to bump our library so version and that would break every existing application unless you would rebuild it to use the new library. That would cause a lot of issues for everyone using libvirt. Yes, dropping old or broken API would allow us to drop a lot of code, on the other hand with the deprecation warning in place and deprecation note in the documentation we can start claiming that these APIs are no longer supported and any bugs caused be these APIs (maybe except for security issues) will not be fixed and in the code we could try to isolate that code as much as possible to make it easier for us. Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
