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.
Michal