This format should be easily readable in the playbook with

- hosts: localhost
  tasks:
    - include_vars:
        file: variable-file.json
        name: variable
    - debug: var=variable

See https://stackoverflow.com/a/50642466 . Or do you prefer something else?

Does anyone know whether it is possible to match multiple names at once? Then we wouldn't need this ugly for loop.

Do we possibly care about a version of any other package?

I'm not actually sure we care about python3-flask-whooshee.

Instead of going with python-rpm, I'd personally only compare plain output of rpm -q --qf %{NAME}-%{VERSION}'\n' python3-whoosh python3-flask-whooshee

anyways, looks fine

Yeah, that's what I wanted to sigh about. The python-rpm API is so user-friendly that I would also probably prefer to just call rpm -qf via subprocess.

You can also try whoosh.versionstring()

Instead of going with python-rpm, I'd personally only compare plain output of rpm -q --qf %{NAME}-%{VERSION}'\n' python3-whoosh python3-flask-whooshee

I've updated the PR to do it this way. PTAL.

I will squash those commits into one before merging. Until then I kept it separated, so we can easily pick which solution we like best.

We had an offlist discussion with @praiskup, that it would make things easier if we had a command deciding whether an indexes rebuild is required (instead of putting that logic into playbooks) and then do the playbook condition this way
https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#overriding-the-changed-result

I've updated the PR to reflect this. PTAL.
(Those commits needs to be squashed before a merge)

Hmm, thinking about it, we run

/usr/share/copr/coprs_frontend/manage.py update_indexes_quick 120

in cron @hourly. But I guess we probably don't want to store a that whooshee version stamp with this command, right? Because in that case, it will appear, that indexes rebuild is not required even though only indexes from the last 120 minutes have been rebuild, not the older ones.

in cron @hourly. But I guess we probably don't want to store a that whooshee version stamp with this command, right?

Good catch.

Don't you want to adjust exit status accordingly? E.g. 0 if "is required" answer is True, 1 if not.

I like this approach, this is easy to employ by playbooks. I originally thought that we'll use only the update_indexes command and adjust it's exit status to:

0 => success
1 => fail
2 => full index not needed

But this approach works as well.

Edit: But if we had only one command -- we'd need something like --force
option probably (we might want to reindex sometimes manually, e.g. if the
cron gets stucked)
Edit 2: So I mean, your aproach is completely equivalent. Don't change it :-)

Don't you want to adjust exit status accordingly? E.g. 0 if "is required" answer is True, 1 if not.

Oh god, I did it exactly the other way. It makes more sense to me though.

Is the indexes update required? Yes! (RC 1)
Is the indexes update required? No! (RC 0)

Or in the meaning of non-zero status code signalizing errors.

Is the indexes update required? Nah, everything is alright (RC 0)
Is the indexes update required? Yep, it otherwise might not work (RC 1)

I've also squashed those commits together and removing the needs-work tag.

I don't really mind so keep this :-) just from commandline user POV, I often do:
selinuxenabled && do_something
(aka 0 when the answer is yes, or "success")

So I'd expect something like:
index_required && do_something

If you reverse the semantics, I'd expect the command to be named like:
index_ok || do_something

But anyways, the exit status is useful thing no matter the semantics you define.

+1 (but the CI badge should be green)

Ah, the CI problem is fixed by 0937dc6. Can you rebase on top of the commit? (I can't do it https://pagure.io/pagure/issue/4596)

Thank you, merging.

Commit fc6855f fixes this pull-request