How to use variant in set_text_variables preflight

[cdwilson]

I'd like to set a text variable named ${VARIANT} in the KiCad schematic title block with the value of the variant global.

I have a KiBot config similar to the following:

preflight:
  set_text_variables:
    - name: VARIANT
      text: '%V'

variants:
  - name: my_variant
    comment: "a comment"
    type: kibom
    file_id: _my_variant
    variant: my_variant
    pre_transform: _var_rename
  - name: another_variant
    comment: "another comment"
    type: kibom
    file_id: _another_variant
    variant: another_variant
    pre_transform: _var_rename

outputs:
  - name: schematic_pdf
    comment: Export the schematic to PDF
    type: pdf_sch_print
    dir: +/Schematic
    options:
      # [string|list(string)='_none'] Name of the filter to mark components as not fitted.
      # A short-cut to use for simple cases where a variant is an overkill
      dnf_filter: _kibom_dnf_BOM
      # [boolean=true] Include the frame and title block
      frame: true
      # [boolean=false] Generate a monochromatic PDF
      monochrome: false
      # [string='%f-%i%I%v.%x'] Filename for the output PDF (%i=schematic, %x=pdf). Affected by global options
      output: '%f-%i%I%v.%x'

However, when I output the schematic PDF with the CLI option -g variant=my_variant, the ${VARIANT} value does not appear to be set:

Is it possible to pass the variant into KiCad as a text variable?

[cdwilson]

FYI, here's what I see in the KiBot debug output:

DEBUG:Preflight apply set_text_variables (kibot.pre_base - pre_base.py:72)
DEBUG:- Current variables: {} (kibot - pre_set_text_variables.py:106)
DEBUG:  - VARIANT -> %V (kibot - pre_set_text_variables.py:125)
DEBUG:- Expanding %X patterns in variables (kibot - pre_set_text_variables.py:127)
DEBUG:  - VARIANT ->  (kibot - pre_set_text_variables.py:134)
DEBUG:- New list of variables: {'VARIANT': ''} (kibot - pre_set_text_variables.py:136)

It seems like %V is expanding to ''

[set-soft]

Hi @cdwilson !
It wasn't possible because preflights doesn't have variants, and they didn't look for a global default variant.
I moved this discussion to #234 to link it with the patches needed to work.
Now should work using the current git code.

[cdwilson]

@set-soft I just tested it on the dev_k6 tag and it appears to be working as expected. Thanks for the quick fix on this!

BTW, I'm brand new to KiBot (as of this week) and your help in these discussions has been greatly appreciated as I'm getting things up and running! I'm kicking myself for not trying it earlier, it makes my KiCad workflow so much better 💪 Thank you!

[cdwilson]

@set-soft I just had a thought about having the VARIANT variable set in the preflight.

With variants, it seems that there are two approaches to generating customized outputs for each variant:

1. Run kibot command multiple times with the same *.kibot.yaml configuration, but specify a different variant via the CLI (e.g. -g variant=my_variant)
2. Run kibot command once, but define the outputs multiple times in the config file with a different variant specified in each output's options section.

I'm currently doing the 1st option (specify variant via CLI), so it's OK that the variant is set once in the preflight at the beginning.

However, if somebody wanted to define a config that generates outputs for multiple variants (2nd option), then having the variant set in the preflight might be problematic (since set_text_variables can only be run once). To support this, it seems like you would need the ability to define an output-specific preflight that runs before each output, rather than a single preflight that runs at the beginning of the job.

Right now, I'm OK with set_text_variables being set once in the preflight (no changes needed), but I just wanted to mention this in case it comes up in the future.

[cdwilson]

Hi @set-soft, thanks for letting me know about this feature. This solves the original problem I posted in this discussion and will probably work for the majority of variant use cases 👍

Just FYI, I probably won't end up using this feature because my variants currently need some additional custom values associated with each variant, and I don't think KiBot currently has a way to support this. As a result, I've ended up just using a python script to generate multiple KiBot config files from a single template file (as I described in #243 (reply in thread)). So far, I've found this has two benefits:

1. I only have to define each KiBot output once in the template and it works across all variants (no need to maintain multiple config files or define the outputs multiple times in the same config for each variant)
2. As far as I can tell, YAML doesn't support text variable substitution. With the Python text substitution in the template, I can use variables (e.g. ${SCHEMATIC_PART_NUMBER} or ${PCB_ASSEMBLY_REVISION}) which can be replaced with different values for each variant config file that is generated. This has ensured that I've only got a single place where these variables are defined, even if they are used in multiple places in the KiBot config.

[set-soft]

2. As far as I can tell, YAML doesn't support text variable substitution.

And now you can use the -E option to do substitution ;-) (08a0628)

[cdwilson]

Cool, I'll test out migrating my project to use the -E option later today.

Just curious, is there a specific reason why you chose the @VARIABLE@ syntax vs. using something "off the shelf" like Template Strings (${variable} syntax) built into python? (asking because I'm already using the ${variable} syntax in my templates, so I'll need to convert them over to @VARIABLE@ syntax)

[set-soft]

Hi @cdwilson !

1. Using ${variable} is not an option, this is the regular UNIX shell mechanism, adopted by KiCad, so you can expect tons of them used for other reasons, and already embedded in the YAML config.
2. @variable@ sequence is completely invalid for YAML, so you'll get an error if any of them isn't replaced, didn't try it with the Python YAML implementation, but the yamllint quickly barfed about it.
3. I used @variable@ for years as a tag for search and replace in many cases, take a look at the README.in.
4. This is the default search & replace pattern used by pcb_replace and sch_replace preflights.

[cdwilson]

Thanks for the explanation.

BTW, the new KiBot preprocessor seems to be working well. I was able to remove my own python preprocessor script/templates from my project. I'll let you know if I run into any issues.

[cdwilson]

As @set-soft mentioned in #233 (reply in thread), support for this was added in 1f1a56e

When the global option set_text_variables_before_output is enabled we run set_text_variables before generating any output that uses variants.