Ansible is capable of many things

Project Discussions
,
16

There is no jinja equivalent, at least none that will work with all ansible-core version starting from 2.12 (including >2.19) and handle not only strings but complex data types (lists, dicts, dicts of lists, etc)

Jinja is bad at handling all but strings, and ansible-core already kinda reverted decision to implicitly convert strings from json starting from 2.19. See -
“Some readers might already have guessed what might be the problem with this solution. It is in ‘from_json’ filter.
In ansible-core 2.19 and above if string looks like a json it is not converted to anything, it will stay string, that is why this filter is required. But in older ansible versions conversion in automatic and when filter is applied it will already be list, and you cannot apply ‘from_json’ filter to list, only to string. Here are executions with different ansible-core versions”
This is from How to solve ansible challenge from ansible-core maintainer

In regards to examples you’ve provided. One of them:

    name: |-
      /etc/systemd/system/k3s
      {%- if not nfc_role_kubernetes_master | default(false) | bool -%}
        -agent
      {%- endif -%}
      .service

There are different methonds of achiving the same result:

  1. ternary filter
    name: |-
      /etc/systemd/system/k3s{{ (nfc_role_kubernetes_master is defined or nfc_role_kubernetes_master) | ternary('-agent', '.service') }}
  1. jinja if expression ( Template Designer Documentation — Jinja Documentation (3.1.x) )
    name: |-
      /etc/systemd/system/k3s{{ '-agent' if (nfc_role_kubernetes_master is defined or nfc_role_kubernetes_master) else '.service' }}

This plugin is along the lines of providing more options to represent logic in ansible. Similar to examples above, where there are at least three options to represent simple logic conditions in ansible. In case of this plugin - logic is represented as data, not as “code”. Data is more convenient to work with in some cases. And this plugin works natively with data, so all the ansible data types are supported and not converted from text. Another benefit is purely visual - all logical operators (AND, OR, NOT) are in prefix notation (before the arguments), this is sometimes more convenient compared to postfix notation (ansible filters) and infix notation (in between - a OR b). Postfix and infix notations are still supported of course.

All the critique in this thread is very much appreciated. It helped to me understand that I failed to highlight the main use case I see for this plugin. There is a common pattern to “set” variables depending (in this case) on os version:

- name: Set version specific variables
  include_vars: "{{ item }}"
  with_first_found:
    - "{{ ansible_distribution }}-{{ ansible_distribution_version }}.yml"
    - "{{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml"
    - "{{ ansible_distribution }}.yml"
    - "{{ ansible_os_family }}.yml"
    - "default.yml"

This is quite bad practice from my point of view. If one have to understand what values will be set for OS <name-X.Y> one has to look for default, os_family, os_name, os_name-X, os_name_X.Y files. It is almost impossible to add complex conditions to action - how to set variable to same value starting with some os version, for instance. How to have different conditions for different variables (one depends on os familiy, another one depends on os version) without duplication? This allows complex data to be set (everything that is possible with var files) - this is benefit compared to jinja. Jinja is a text templating engine and supports only text.

Filter capable.core212.logical is a way to resolve all the mentioned issues. While providing interface that is easy to read and reason about.
Flexible conditions are possible, values are returned natively.

The code above (with with_first_found) is much better represented (from my point of view) and much more flexible using capable.core212.logical filter.

- name: Set version specific variables
  vars: 
      variable_conditions: 
         if: false
         then: false
         elseif:
            - elseif: "{{ ansible_facts['os_distribution'] == 'os_name' and ansible_facts['distribution_major_version'] == X }}"
              then: "{{ value_os_distribution_X }}"
....
          else: "{{ default_value }}"
      variable: "{{ variable_conditions | capable.core212.logical }}"

Main idea of this plugin is to use it when one has to return complex data types (dicts, lists of dicts, dicts of lists, etc) and conditions are relatively complex or multiple (several elseif).