Consider a different name than defined for customizations?

[mvo5]

I am struggling a bit with the name defined in customizations,

I was playing with various ideas, here are some for your consideration:

name: tree
build: name:root
stages:
...yaml
  - type. org.osbuild.hostname:
    options:
      hostname:
        otk.customization.hostname:
          default: localhost.localdomain
          if-defined: $this.hostname
          is-set: $this.hostname
          if-set:  $this.hostname
          set: $this.hostname

(obvious only one of the last couple)

or mabe just:

  - type. org.osbuild.hostname:
    options:
      hostname:
        otk.customization.hostname:
          default: localhost.localdomain

and we just replace otk.customization.hostname with it's value if it's not the default?

[supakeen]

I agree I don't particularly like defined and am not sure what it should be. set comes closest to my expectations.

The second variant I'm not too fond of, sometimes customizations will need to create (multiple) objects in the tree and it would lead to having to put all of that in the customization value. Take for example a file customization that needs to create the file with its contents, chmod, and chown it, and perhaps sets extended attributes :)

[achilleas-k]

I'm having a hard time understanding exactly how this works by reading the spec and the discussion, even though I came in thinking I did.

From the spec:

otk/doc/directives.md

Lines 169 to 172 in e57456a

	Customizations are conditional blocks that receive separate input through
	`otk compile -Cname=data`, a customization is considered to be active when it
	is passed data. If a customization is passed multiple times then the `defined`
	block is replaced multiple times, once for each data input.

Customizations are conditional blocks that receive separate input through otk compile -Cname=data,

Ok so far

a customization is considered to be active when it is passed data.
What does active (vs inactive) mean exactly? Taking the example

otk.customization.name:
  default:
    - type: org.osbuild.stage
      options: none
  defined:
    - type: org.osbuild.stage
      options: ${this.data}  # it's not going to be `this`
    - type: org.osbuild.stage
      options: ${this.data}  # it's not going to be `this`

would an inactive customization mean that the stage isn't added, or that it's added without options (because of the default)?

If a customization is passed multiple times then the defined block is replaced multiple times, once for each data input.

Does replacing the block multiple times mean that we get multiple stages, one for each customization, or that the same block is replaced each time and only the last one essentially remains?

For the actual topic at hand:
I kinda like the if- prefixed versions of the options, and I'm leaning towards if-set. It reads clearer to me saying "if thing is set: write hostname".

(I didn't mean to nitpick as much as I did, just felt that it was worth bringing up the confusion I had so we can make things clearer if possible)

[supakeen]

I'm having a hard time understanding exactly how this works by reading the spec and the discussion, even though I came in thinking I did.

From the spec:

otk/doc/directives.md

Lines 169 to 172 in e57456a

	Customizations are conditional blocks that receive separate input through
	`otk compile -Cname=data`, a customization is considered to be active when it
	is passed data. If a customization is passed multiple times then the `defined`
	block is replaced multiple times, once for each data input.

Customizations are conditional blocks that receive separate input through otk compile -Cname=data,

Ok so far

a customization is considered to be active when it is passed data.
What does active (vs inactive) mean exactly? Taking the example

otk.customization.name:
  default:
    - type: org.osbuild.stage
      options: none
  defined:
    - type: org.osbuild.stage
      options: ${this.data}  # it's not going to be `this`
    - type: org.osbuild.stage
      options: ${this.data}  # it's not going to be `this`

would an inactive customization mean that the stage isn't added, or that it's added without options (because of the default)?

If a customization is passed multiple times then the defined block is replaced multiple times, once for each data input.

Does replacing the block multiple times mean that we get multiple stages, one for each customization, or that the same block is replaced each time and only the last one essentially remains?

For the actual topic at hand: I kinda like the if- prefixed versions of the options, and I'm leaning towards if-set. It reads clearer to me saying "if thing is set: write hostname".

(I didn't mean to nitpick as much as I did, just felt that it was worth bringing up the confusion I had so we can make things clearer if possible)

This type of nitpicking is very necessary.

What does active (vs inactive) mean exactly? Taking the example

Active means the customization is passed on the command line. Inactive means it wasn't.

would an inactive customization mean that the stage isn't added, or that it's added without options (because of the default)?

The default case would execute for an inactive customization. Hence only a single stage (with options none) would be added.

Does replacing the block multiple times mean that we get multiple stages, one for each customization, or that the same block is replaced each time and only the last one essentially remains?

It means the defined block is repeated one time for each time the customization is passed. So if it's passed twice in this case we'd end up with 4 stages.

The example isn't the best anymore, there's now a 'real-life' usecase where repeating doesn't make sense: https://github.com/osbuild/otk/blob/main/example/fedora/osbuild/pipeline/tree.yaml#L22

[supakeen]

I kinda like the if- prefixed versions of the options, and I'm leaning towards if-set. It reads clearer to me saying "if thing is set: write hostname".

Agreed. I like that one the most as well. Does the default name still feel good?

Note that if there is no default key and the customization is inactive then the entire customization would be a no-op, this also needs docs.

[achilleas-k]

I kinda like the if- prefixed versions of the options, and I'm leaning towards if-set. It reads clearer to me saying "if thing is set: write hostname".

Agreed. I like that one the most as well. Does the default name still feel good?

I think so, yeah. That's very clear.

Note that if there is no default key and the customization is inactive then the entire customization would be a no-op, this also needs docs.

Makes sense!

[supakeen]

There's now a PR open that renames defined -> if-set.

[supakeen]

Merged in #26.