After the switch of 'my_clean' to a simple Command, the 'clean' command
has no more bits for options, resulting in distutils (either external
or embedded in setuptools) complaining about it:

  distutils.errors.DistutilsClassError: command class <class '__main__.my_clean'> must provide 'user_options' attribute (a list of tuples)

To overcome that, provide all the standard bits from options, i.e. the
'user_options' list, and the 'initialize_options' & 'finalize_options'
methods. In addition, add a dummy 'all' option, as distutils wants it:

  error: error in [...]/.pydistutils.cfg: command 'my_clean' has no such option 'all'

Fixes commit a965c91c6fa1275613edbbef75c0422574eb9ff2

Signed-off-by: Pino Toscano <ptoscano@redhat.com>

Add classifiers that indicate we intend to support python versions
3.9 and 3.10.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

In Python 3.10 the setDaemon method was deprecated. It is redundant
since the 'daemon' parameter can be given when creating the thread,
or the 'daemon' attribute can be set after it was created.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Add a test for one more usage scenario that was possible in the past,
whereby libvirt events are registered before starting the asyncio
loop, but we let libvirt find the loop associated with the current
thread.

Skip the test relies on auto-creating an event loop with Python >= 3.10
since it now triggers a deprecation warning which will soon turn into a
RuntimeError.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

We currently have to run each of the test_aio.py test cases in a
separate process, because libvirt.virEventRegisterImpl can only be
called once per process. This leads to quite unpleasant console
output when running tests.

By introducing a mock for libvirt.virEventRegisterImpl we can
regain the ability to run everything in a single process. The only
caveat is that it relies on tests to fully cleanup, but in practice
this is ok for our current tests.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Chris Gunn <chrisgun@microsoft.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

The drain method uses an asyncio.Event object to be notified when other
coroutines have removed all registered callbacks. The Event object needs
to be associated with the coroutine that the event loop is running with
and currently this is achieved by passing in the 'loop' parameter.

Unfortunately Python 3.10 has removed the 'loop' parameter and now the
object is associated implicitly with the current thread's event loop.
At the time the virEventAsyncIOImpl constructor is called, however,
there is no guarantee that an event loop has been set for the thread.
The explicitly passed in 'loop' parameter would handle this scenario.

For portability with Python >= 3.10 we need to delay creation of the
Event object until we have a guarantee that there is a loop associated
with the current thread. This is achieved by lazily creating the Event
object inside the 'drain' method, which is expected to be invoked from
coroutine context and thus ensure a loop is associated.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

The 'async' keyword is new in Python 3.5, as a way to declare that a
method is a coroutine. This replaces the '@asyncio.coroutine' decorator
that is deprecated since 3.8 and scheduled to be removed in 3.11

The 'await' keyword has to be used instead of 'yield' from any
coroutines declared with 'async'.

Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
[DB: Split off from a larger patch mixing multiple changes]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

setup.py ensures we have python >= 3.5, so there is no need to do
back compat with the 'asyncio.ensure_future' method, which was new
in 3.4.4

Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
[DB: Split off from a larger patch mixing multiple changes]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>