`FlatpakPackages` fact incorrectly drops the first installed package

[vivienm]

Describe the bug

The FlapakPackages fact may drop the first installed package.

Its process method unconditionally drops the first line from the output of the flatpak list command:

pyinfra/src/pyinfra/facts/flatpak.py

Lines 71 to 77 in 9efcb40

	@override
	def command(self):
	return "flatpak list --columns=application"
	@override
	def process(self, output):
	return [flatpak for flatpak in output[1:]]

I suspect this code assumes this first line is a header:

$ flatpak list --columns=application
Application ID
com.calibre_ebook.calibre
com.github.PintaProject.Pinta
com.github.tchx84.Flatseal
...

But this is not always true. At least some versions of flatpak seem to check whether the terminal is a TTY and, when not, remove the header:

$ flatpak list --columns=application | cat
com.calibre_ebook.calibre
com.github.PintaProject.Pinta
com.github.tchx84.Flatseal
...

As a result, the first entry (here, com.calibre_ebook.calibre) is missing from the fact output:

$ pyinfra inventory.py fact pyinfra.facts.flatpak.FlatpakPackages
--> Loading config...
--> Loading inventory...
--> Connecting to hosts...
    [deuterium] Connected

--> Gathering facts...
    [deuterium] Loaded fact flatpak.FlatpakPackages

--> Fact data for: flatpak.FlatpakPackages
{
    "deuterium": [
        "com.github.PintaProject.Pinta",
        "com.github.tchx84.Flatseal",
...

To Reproduce

Steps to reproduce the behavior, please include where possible:

• Operation code & usage
• Target system information

$ lsb_release -a
LSB Version:	n/a
Distributor ID:	Bluefin
Description:	Bluefin (Version: 43.20251230.1)
Release:	43
Codename:	Deinonychus

$ flatpak --version
Flatpak 1.16.1

• Example using the @docker connector (helps isolate the problem)

Expected behavior

The FlatpakPackages fact should correctly identify all installed packages, including the first one, regardless of whether the header is present or not.

Meta

• Include output of pyinfra --support.

$ pyinfra --support

    If you are having issues with pyinfra or wish to make feature requests, please
    check out the GitHub issues at https://github.com/Fizzadar/pyinfra/issues .
    When adding an issue, be sure to include the following:

    System: Linux
      Platform: Linux-6.18.2-arch2-1-x86_64-with-glibc2.42
      Release: 6.18.2-arch2-1
      Machine: x86_64
    pyinfra: v3.5.1
      click: v8.3.1
      distro: v1.9.0
      gevent: v25.9.1
      jinja2: v3.1.6
      packaging: v25.0
      paramiko: v3.5.1
      python-dateutil: v2.9.0.post0
      typeguard: v4.4.4
      typing-extensions: v4.15.0
    Executable: /home/vivien/perso/scratch/pyinfra/deploys/ublue-system/.venv/bin/pyinfra
    Python: 3.12.11 (CPython, Clang 20.1.4 )

• How was pyinfra installed (source/pip)?

Using uv.

• Include pyinfra-debug.log (if one was created)
• Consider including output with -vv and --debug.

None was created (no crash).

[vivienm]

I've been using this workaround:

def flatpak_packages_process(self: FlatpakPackages, output: Iterable[str]) -> list[str]:
    return [
        flatpak
        for i, flatpak in enumerate(output)
        if i != 0 or flatpak != "Application ID"
    ]


FlatpakPackages.process = flatpak_packages_process

I can propose a PR if the principle (filtering on condition i != 0 or flatpak != "Application ID") is OK.