* dconf - Try to find a Python interpreter that has gi.repository.GLib
If we're invoked in a Python interpreter that doesn't have access to
`gi.repository.GLib`, try to find one that does and respawn the task
in that interpreter.
* ChangeLog fragment for #6491
* Update changelogs/fragments/6491-dconf-respawn.yml
Co-authored-by: Felix Fontein <felix@fontein.de>
* Simplify import code
* Get rid of ModuleNotFoundError
---------
Co-authored-by: Felix Fontein <felix@fontein.de>
* dconf: Correctly handle setting a key that has no value in DB
We need to check if the value in the database is None before we try to
parse it, because the GVariant parser won't accept None as an input
value. By definition if the value is None, i.e., there's no value in
the database, than any value the user is trying to set is a change, so
just indicate that it's a change without trying to compare the None to
whatever the user specified as the value.x
* dconf: Give a more useful error when writing a key fails
if writing a key fails, then include in the error that is returned the
exact key and value aguments that were given to the dconf command, to
assist in diagnosing failures caused by providing the key or value in
the wrong format.x
* dconf: Convert boolean values into the format that dconf expects
Even though we warn users to be careful to specify GVariant strings
for values, a common error is to be trying to specify a boolean string
which ends up getting converted into a boolean by the YAML parser or
Ansible. Then it gets converted to "True" or "False", the string
representations of Python booleans, which are not valid GVariants.
Rather than just failing with an obscure error when this happens,
let's be more user-friendly and detect when the user has specified a
boolean and convert it into the correct GVariant forms, "true" or
"false", so it just works. There's no good reason to be more pedantic
than that.
dconf: parse GVariant values to check for equality whenever possible
Direct string comparisons are an inaccurate way to compare two
GVariant representations. For example, 'foo' and "foo" (including the
quote marks, which are part of the representation) are equal GVariants
but if you just do a string compare (remember, including the quotes)
they'll be interpreted.
We therefore want to use the `gi.repository` Python library to parse
GVariant representations before comparing them whenever possible.
However, we don't want to assume that this library will always be
available or require it for Ansible to function, so we use a straight
string comparison as a fallback when the library isn't available. This
may result in some false positives, i.e., Ansible thinking a value is
changing when it actually isn't, but will not result in incorrect
values being written into `dconf`.
Co-authored-by: Jonathan Kamens <jik@jik5.kamens.us>
