How can complex lists be defined in YAML?

That's a fantastic follow-up question! You're clearly trying to get a solid grasp on YAML, which is great.

You've already seen an example of a "complex" list with your inputs and roles definitions. "Complex lists" in YAML typically mean lists where the items are not just simple scalar values (like numbers or strings), but rather are objects (key-value maps) or even other lists.

Let's break down the different ways to define complex lists in YAML:

1. List of Objects (Maps)

This is what you saw with your inputs example. Each item in the list is a mini-configuration in itself, identified by a key-value structure.

Example: List of users, each with properties like name, age, and isAdmin.

users:
  - name: Alice
    age: 30
    isAdmin: true
  - name: Bob
    age: 24
    isAdmin: false
  - name: Charlie
    age: 35
    isAdmin: true

• users: is a key whose value is a list.
• Each line starting with - is an item in the users list.
• Each list item is an object (or map), containing name, age, and isAdmin as its own keys.

2. List of Lists (Nested Lists)

You can have lists where each item is itself another list.

Example: A matrix (a list of rows, where each row is a list of numbers).

matrix:
  - - 1
    - 2
    - 3
  - - 4
    - 5
    - 6
  - - 7
    - 8
    - 9

• matrix: is a key whose value is a list.
• The first - indicates an item in matrix.
• The second - on the same line indicates an item in the inner list.
• This creates a structure like [[1, 2, 3], [4, 5, 6], [7, 8, 9]].

3. Combining Objects and Lists within a List

You can mix and match. An item in a list could be an object, which then contains another list, or vice versa. Your inputs example already did this (inputs is a list of objects, and one of those object's keys, roles, has a value that is a list of strings).

Example: A list of tasks, where each task has a name and a list of subtasks.

projects:
  - name: Website Redesign
    tasks:
      - Design Layouts
      - Develop Frontend
      - Develop Backend
      - Deploy to Production
  - name: Mobile App Update
    priority: High
    tasks:
      - Fix bugs
      - Add new features

• projects: is a list of objects.
• Each object has a name key and a tasks key.
• The tasks key itself has a value that is a list of simple strings.

4. Flow Style (Inline Notation)

For simpler complex lists, or if you prefer a more compact look, you can use "flow style" (much like JSON array and object notation).

Example using flow style:

users_inline: [ {name: Alice, age: 30}, {name: Bob, age: 24} ]

matrix_inline: [ [1, 2, 3], [4, 5, 6] ]

projects_inline:
  - {name: Website, tasks: [Design, Develop]}
  - {name: Mobile, priority: High, tasks: [Fix, New Features]}

• Square brackets [] denote lists.
• Curly braces {} denote objects (key-value maps).
• Items are separated by commas.
• While compact, this can become harder to read for very deeply nested or large structures. The "block style" (using indentation and hyphens) is generally preferred for readability in configuration files.

Key Rules for Defining Complex Lists:

• Indentation is king: Always use consistent indentation (usually 2 or 4 spaces) to define the hierarchy.
• Hyphen (-) for list items: Every item directly in a list must start with a hyphen followed by a space.
• Key-value pairs (key: value): Objects are defined by indented key-value pairs.
• Context matters: The meaning of key: or - is defined by its indentation level relative to parents.

The inputs section from your Frigate config is a perfect illustration of how common and useful complex lists (specifically, "list of objects") are in YAML for defining structured configurations.

Does this breakdown help clarify how to structure and interpret complex lists in YAML?