On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote: > On 10/02/2018 05:38 PM, Pavel Hrdina wrote: > > On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote: > >> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote: > >>> Background > >>> ========== > >> > >> [...] > >> > >>> Two concrete examples are considered here: one is the > >>> virConnectNumOfDomains() API which, while known to be racy and having > >>> non-racy alternatives, can still be used by developers without > >>> getting any kind of warning in the process; the other one is the > >>> ability to define a domain without specifying the machine type, which > >> > >> Okay, but for these particular ones we could do a compile time warning. > >> Not that we ever can remove them though. > > > > Definitely agree with Peter, having a runtime warning for issue that > > you cannot change in runtime situation is IMHO wrong. Even though we > > cannot remove any API the deprecation warning can be still useful > > because it can suggest better API to use instead of the old one. > > So two of our biggest consumers use python bindings. I'm failing to see > how a compile time warning would help here. E.g. if an app is using > "conn.conn.numOfDefinedDomains()" we could call > virConnectListAllDomains() with appropriate flags. Except we can't, > because then the app would be unable to talk to older libvirtds where > the procedure doesn't exist. > > In other words, if our goal is to make users switch to newer versions of > functions then we might have to find a better solution (than compilte > time warnings). Runtime warnings would work with python though. As John's pointed out in his reply, given our API contract, we're providing devs of apps built on top of libvirt with certain guarantees, so it's fair to assume they'd just ignore the warnings, since we can't break our contract and their product keeps working anyway, so "why bother changing it", right? Unfortunately, I feel it's a common practice not to change anything unless it stops working and there might even be very legitimate reasons for such a practice, like simply not enough man power. Therefore I myself don't see any mass adoption/switch to the new preferred/safe versions of our APIs any time soon. The only effect you'd IMHO achieve by having runtime warnings is log pollution. Having said that, I don't have any better ideas on how we could achieve this brave goal without using the obvious drastic measures. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
