Review external/language support for arithmetic

[mvo5]

We currently have: 9745d21#diff-25d48cd0a80de2fc2e346a35770961b580c16096f70463c0f8ea58a61a1eb0b0R8

The rootfs for the iso installer is currently setup like this:

otk.define:
  ...
  size_iso_efiboot: '20971520'
  size_iso_efiboot_in_sectors: 40960

where size_iso_efiboot_in_sectors is just size_iso_efiboot / 512. So think about something like:

1. ${size_iso_efiboot / 512} to avoid size_iso_efiboot_in_sectors or
2. supporting "size_iso_efiboo` directly in the "truncate" stage (i.e. a new input like "size_in_byte") or
3. an external

otk.define:
 size_iso_efiboot: '20971520'
 otk.external.calc:
   define: size_iso_efiboot_in_sectors
   calc: ${size_iso_efiboot} / 512

(or something else)

[cgwalters]

I don't mean to pick on this issue specifically but there's multiple existing "configuration languages" that exist, many have reached a stable point and have some ecosystem. While I've only played with it superficially my favorite is Nickel, which has functions for exactly things like arithmetic: https://nickel-lang.org/user-manual/syntax#functions (But it's not arbitrary code either, it has schemas etc.) https://github.com/tweag/nickel?tab=readme-ov-file#comparison links to many others.

[mvo5]

Thanks Colin, I think we reached the point where we need to explore exactly this to avoid that we create the 27th (not very good) mini language.

[edit: fwiw, I liked starlark in the past but I have not looked at any of this in a while]

[supakeen]

I don't mean to pick on this issue specifically but there's multiple existing "configuration languages" that exist, many have reached a stable point and have some ecosystem. While I've only played with it superficially my favorite is Nickel, which has functions for exactly things like arithmetic: https://nickel-lang.org/user-manual/syntax#functions (But it's not arbitrary code either, it has schemas etc.) https://github.com/tweag/nickel?tab=readme-ov-file#comparison links to many others.

I very much dislike the need for implementing something based on YAML as well; however it was the pragmatic way forwards initially.

The main goal for otk is to move image definitions from (Go) code in images to a more declarative language which allows users (read: distribution maintainers, including ourselves) to maintain image definitions upstream and modify them without needing to learn Go.

Users (read: distribution maintainers) are often familiar with YAML (or JSON), the format we use here is close to Ansible playbooks (on purpose). When speaking to some of those users they have expressed their willingness to work with YAML.

One of the core problems we've had with using configuration DSLs such as nickel or jsonnet is the extensibility, supportedness, maturity, and also arguably the complexity. To take nickel as an example it is (similar applies to others):

• Not extensible; we cannot define nor ship our externals such as dependency solving where we need to interact with libraries.
• Not packaged for Debian, Ubuntu, Fedora, CentOS, nor RHEL.
• It is another DSL users have to learn.

None of those are unsolvable, the last one even applies to the current YAML DSL we have as well but they do make this a very not-so-easy problem.

[supakeen]

Thanks Colin, I think we reached the point where we need to explore exactly this to avoid that we create the 27th (not very good) mini language.

[edit: fwiw, I liked starlark in the past but I have not looked at any of this in a while]

We can have this discussion again if we want, this time in a public forum. However it would need to involve potential future users as well. Those currently have no complete examples of how this would work and look.

We'd need a concrete comparison between these approaches before we can have a valuable discussion about this.

I'd suggest that if we want to explore these DSLs again to write PRs to implement current YAML omnifests without the use of the currently provided externals (as they are part of the programming language, I guess?). These examples can go into example/${dsl}/centos and be added to image reference testing.

[mvo5]

A pragmatic consideration might be to consider introducing jinja2 before we implement more extension (like arithmetic) into ${} with jinja2 things would largely stay the same otherwise. But let's continue with what have right now we are not blocked on any of this.