IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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>
The python lxml registers some global callbacks with libxml2. As a
result when another user of libxml2 calls APIs, it can trigger the
python callbacks that lxml previously registered. Execution of the
python callbacks in this case is often unsafe and leads to SEGVs.
This hasn't been a problem since the sanitytest.py test has been
a standalone program we execute. When it gets turned into a real
python unit test, it will run in the same process as all the other
tests and trigger the crash.
A mitigation was added in lxml 4.5.2 which is good enough to let
us continuing using lxml.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sanitytest.py file is now using the normal python unittest
pattern, though we invoke the one test explicitly for now.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We want to move over to make sanitytest.py operate like a more normal
test script, which means making it self contained.
The setup.py already sets the PYTHONPATH thanks to changes introduced
in:
commit eaded7bdad
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Tue Mar 18 11:11:48 2014 +0000
Add support for running unit tests with nose
so passing the python module path into sanitytest.py is redundant.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We want to move over to make sanitytest.py operate like a more normal
test script, which means making it self contained.
The test already knows how to find the libvirt API XML path using
pkg-config and if an override location is required, this can be done
by pointing $PKG_CONFIG_PATH to a suitable place.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The distutils package is deprecated and targetted for deletion in Python
3.12, so we need to switch to setuptools. Thanks to all the preceeding
changes this is no more difficult than changing the import statements.
Closes https://gitlab.com/libvirt/libvirt-python/-/issues/1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'get_platform' function is used to determine the platform specific
component of the build output directory containing the loadable
modules and python code. There is no nice replacement for this
function, but we can achieve our goal by simply scaning for the desired
subdirectory, which should exist by the time 'test' runs.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We override the 'build' command to invoke the code generator before the
extensions are compiled. The 'build' command, however, is merely a
wrapper around several other commands. It is possible for the user to
directly invoke those commands, in which case our code generator won't
get a chance to run:
$ python setup.py build_ext
running build_ext
building 'libvirtmod' extension
creating build/temp.linux-x86_64-3.10
creating build/temp.linux-x86_64-3.10/build
gcc ..snip... -c build/libvirt.c -o build/temp.linux-x86_64-3.10/build/libvirt.o
cc1: fatal error: build/libvirt.c: No such file or directory
compilation terminated.
error: command '/usr/lib64/ccache/gcc' failed with exit code 1
To solve this we instead override 'build_ext' and 'build_py'. This in
turn means we call the generator to emit C code separately from Python
code.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The distutils.dir_util.remove_tree method has no compelling benefit
over using the standard python shutils module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The distutils.spawn method has no compelling benefit over using the
standard python subprocess module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The distutils.spawn.find_executable method has no compelling benefit
over using the standard python shutils module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of searching for the pkg-config binary manually, just try to run
it and catch the exception raised if it isn't found. Use the --version
flag as a way to validate that it is at least somewhat functional.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The default 'clean' command impl deletes only intermediate files from
the 'build' directory. We've overridden it to delete everything. There
is no benefit in inheriting from the default impl, given our subclass
will delete everything.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we always generate both the C code and Python code at the same
time. To cope with following changes to the build process, we want to be
able to generate C and Python separately.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The python generator needs to know whether certain functions were
skipped in the C generator. This is achieved by the C generator
deleting skipped functions as it runs. This is an unhelpful side
effect as it makes it impossible to run the python generator
without first running the C generator.
This refactors buildStubs to get rid of the global side effects
it has, by providing some helper functions for buildWrappers
to use.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As a side effect of generating the C code, the buildStubs methods
checks for various unsupported types and reports errors. This is
an undesirable side effect, if we want to skip C code generation.
Splitting function type validation out into a separate method
allows better reuse.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The buildStubs method has a side effect of loading and parsing the API
XML files, which the buildWrappers method then relies on.
Splitting API loading into a separate method will facilitate running
only the buildWrappers method in future.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of having three separate methods for generating python
wrappers, merge them all together.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we're using common data structures for all the main libvirt,
QEMU and LXC APIs, several of the functions have code duplication
that can be eliminated.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we only use a single dict for tracking all enums, we
only need a single function for registering them.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking enums.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we only use a single dict for tracking all functions, we
only need a single function for registering them.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking skipped functions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking functions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The distutils/setuptools 'install' command is deprecated in favour of
'pip', and with recent versiosn, using it will create a bad install
that triggers a traceback on all future use of setuptools:
Traceback (most recent call last):
File "/builds/berrange/libvirt-python/setup.py", line 328, in <module>
setup(name = 'libvirt-python',
File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 154, in setup
_install_setup_requires(attrs)
File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 143, in _install_setup_requires
dist = MinimalDistribution(attrs)
File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 135, in __init__
super().__init__(filtered)
File "/usr/lib/python3.10/site-packages/setuptools/dist.py", line 456, in __init__
for ep in metadata.entry_points(group='distutils.setup_keywords'):
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1009, in entry_points
return SelectableGroups.load(eps).select(**params)
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 459, in load
ordered = sorted(eps, key=by_group)
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1006, in <genexpr>
eps = itertools.chain.from_iterable(
File "/usr/lib64/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
k = key(element)
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 941, in _normalized_name
return self._name_from_stem(stem) or super()._normalized_name
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 622, in _normalized_name
return Prepared.normalize(self.name)
File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 871, in normalize
return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
File "/usr/lib64/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
This is certainly a bug in distutils/setuptools, but given the
'install' command is deprecated, instead of waiting for a fix,
just switch to the recommend 'pip install .' command.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With libvirt-8.2.0 there's a new API:
virDomainQemuMonitorCommandWithFiles(). Since the API has both
input and output arguments we need to provide an alternative
implementation. Moreover, since FD passing works only on
UNIX-like systems we can query the returned FDs for their flags
and construct mode for python File object.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
