repolist: Implement JSON output

[jan-kolarik]

• Created shared --json option for requesting output in JSON format
• Implementation for repo list command

For: #867.

[jan-kolarik]

Example output:

[root@71dd3fed55a5 dnf5]# dnf5 repo list --json
[
  {
    "id":"copr:copr.fedorainfracloud.org:rpmsoftwaremanagement:dnf-nightly",
    "name":"Copr repo for dnf-nightly owned by rpmsoftwaremanagement",
    "is_enabled":true
  },
  {
    "id":"copr:copr.fedorainfracloud.org:rpmsoftwaremanagement:test-utils",
    "name":"Copr repo for test-utils owned by rpmsoftwaremanagement",
    "is_enabled":true
  },
  {
    "id":"updates",
    "name":"Fedora 39 - x86_64 - Updates",
    "is_enabled":true
  },
  {
    "id":"fedora-cisco-openh264",
    "name":"Fedora 39 openh264 (From Cisco) - x86_64",
    "is_enabled":true
  },
  {
    "id":"fedora",
    "name":"Fedora 39 - x86_64",
    "is_enabled":true
  }
]

[jan-kolarik]

The question is also if to have consistent attributes in the JSON output or if to filter some (like is_enabled) based on the user input.

[kontura]

Does this need to be stored in the Context?

It seems the value is used only in the commands, to make it simpler I would store it there.
It could use libdnf5::cli::session::BoolOption, for example like advisory SecurityOption?

[jan-kolarik]

I've been already working on the follow-up repoinfo implementation and there I am calling the set_quiet(true) when json output is requested to have really just the JSON on the output, so it's also parsable. In this regard, this place is handy.

[kontura]

I see, however doesn't that have the same issue as mentioned in #1524?
That is dnf5 repo info --quiet --refresh prints REPOSYNC to stdout which would ruin the json.

[jan-kolarik]

Hmm, you're right this is happening, though I'd think it's suppressed by this line: https://github.com/rpm-software-management/dnf5/blob/5.2.3.0/dnf5/main.cpp#L1192. So it seems like a bug to me right now. I am still planning to do such binding to quiet there...

[jan-kolarik]

So the issue is that the ^ mentioned callbacks setup should be done after parsing the command line arguments. Then the quiet is taken into account. Tested locally and seems working 🙂

[kontura]

Thank you for looking into it.

[kontura]

The question is also if to have consistent attributes in the JSON output or if to filter some (like is_enabled) based on the user input.

Personally I prefer consistent attributes, I believe it will be less error prone.