fix(inventory): mark plugin-supplied strings as trusted for ansible-core 2.19+

[BeArchiTek]

Related Issue

#323

New Behavior

The opsmill.infrahub.inventory dynamic inventory plugin now produces clean JSON in ansible-inventory --list on ansible-core 2.19+. Plugin-supplied string values are tagged with ansible.template.trust_as_template so the legacy inventory JSON encoder serialises them as plain strings rather than {"__ansible_unsafe": "..."} dictionaries.

Supported-version metadata is also refreshed and aligned across pyproject.toml, meta/runtime.yml, tox-ansible.ini, README, and the installation guide:

• requires-python = ">=3.11,<3.15" (allows Python 3.14, which ansible-core 2.20 is the first to officially support)
• ansible-core>=2.18 floor; requires_ansible: ">=2.18.0" in meta/runtime.yml (was >=2.16.0 and inconsistent with pyproject)
• tox-ansible.ini skip list updated: drops py3.10 and ansible-core 2.17 (both below the new floor), unblocks py3.14
• uv.lock regenerated against the new floor

Contrast to Current Behavior

Before this PR, running ansible-inventory --list against ansible-core 2.19 / 2.20 returned every string host variable wrapped as {"__ansible_unsafe": "value"}, e.g.:

"device1": {
    "id": { "__ansible_unsafe": "18285863-877d-7985-3073-1065c12da389" },
    "position": { "__ansible_unsafe": "28" }
}

After this PR the output is the same shape as on ansible-core 2.18:

"device1": {
    "id": "18285863-877d-7985-3073-1065c12da389",
    "position": "28"
}

On ansible-core < 2.19 the behaviour is unchanged (the trust shim is a no-op).

The version-floor changes drop already-EOL combinations (Python 3.10, ansible-core 2.17) instead of carrying configuration that no longer matches reality. The previous pyproject.toml upper bound <3.14 blocked Python 3.14 entirely even though ansible-core 2.20 supports it; the new ceiling <3.15 admits 3.14.

Discussion: Benefits and Drawbacks

• Restores the documented and expected ansible-inventory --list JSON shape, which is consumed verbatim by downstream tooling (AWX, ansible-navigator, custom scripts that parse _meta.hostvars).
• Fix is centralised in set_hosts_and_groups and gated by ImportError, so it is a no-op on older ansible-core and adds no runtime cost there.
• Strings from Infrahub are now marked as trusted for templating. This is acceptable because Infrahub is the source of truth for inventory data; users who put {{ ... }} literals into Infrahub attributes will see them rendered, but that surface area was already implicit when those values flowed into Ansible variables.
• Backwards compatibility: the bug fix itself is fully backwards-compatible. The version-floor bumps (ansible-core>=2.18, python>=3.11) are breaking for any consumer still on EOL ansible-core 2.17 or Python 3.10; both tracks are already past their official EOL dates per the ansible-core support matrix.

Changes to the Documentation

• README.md: requirements section now states Python >=3.11, <3.15 and Ansible 2.18+.
• docs/docs/guides/installation.mdx: requirements section now states Python 3.11+ and Ansible 2.18+.

Proposed Release Note Entry

Fix opsmill.infrahub.inventory so ansible-inventory --list returns plain JSON strings instead of {"__ansible_unsafe": "..."} wrappers under ansible-core 2.19+ (#323). Bump supported floors to Python 3.11 and ansible-core 2.18; allow Python 3.14.

Double Check

• I have explained my PR according to the information in the comments or in a linked issue.
• My PR targets the develop branch.

[cloudflare-workers-and-pages]

Deploying infrahub-ansible with    Cloudflare Pages

Latest commit:	7fcdf82
Status:	✅  Deploy successful!
Preview URL:	https://ed7f429c.infrahub-ansible.pages.dev
Branch Preview URL:	https://claude-expand-python-version.infrahub-ansible.pages.dev

View logs