Metadata in config sections

[pedrolamas]

Both Fluidd and Mainsail currently use the gcode_macro variables to allow users to set and pass metadata to them.

Take for example how mainsail-config and fluidd-config set the user defaults.

Another example, in Fluidd one can add variable_ignore_min_extrude_temp: True to the LOAD_FILAMENT, UNLOAD_FILAMENT, M701, and M702 macros to ignore the extruder temperature.

This is obviously a hack, so I would like to propose an alternative that could even be used across every section and not just the gcode_macro sections!

Option 1: single “meta” attribute:

Allow for a single meta attribute, so users can pass whatever they want inside and it will be considered as pure text.

Example:

[mcu]
serial: /tmp/pseudoserial
restart_method: Arduino
meta
    test: 1

[virtual_pins]
meta:
    whatever

The value is not used anywhere on Klipper and s only exposed on the configfile status object:

Option 2: “meta_” prefixed attributes:

Allow for meta_ prefixed attributes, so users can pass whatever they want inside and it will be considered as pure text.

Example:

[mcu]
serial: /tmp/pseudoserial
restart_method: arduino
meta_test: 1

[virtual_pins]
meta_other: whatever

The value is not used anywhere on Klipper and s only exposed on the configfile status object:

---

My personal opinion goes that option 2 is preferred!

Both solutions are really easy to implement with a single change on check_unused_options method on Klipper’s configfile.py

[pedrolamas]

I’ve now opened a Pull Request with Option 2 implemented if anyone wants to try and provide feedback:

configfile: adds meta options

[koconnor]

Interesting.

I certainly don’t see an issue with extending the config file to add useful features for the frontends.

For what it is worth though, I’d much prefer to understand a concrete “use case” for the support. The description above doesn’t give me a good feeling for the intended functionality this change would provide (at least initially).

I’m generally leery about adding new config items, for fear that it makes the config more complex. I’m also leery about adding “it can do anything” config items as I fear that is a disservice to users that ultimately need to configure them to accomplish specific results.

Cheers,
-Kevin

[flowerysong]

Yes, a concrete description of a use case that variables are not usable for would be nice.

You describe the use of variables as “a hack”, but the first examples you provided don’t really fit that description. These are user-settable variables that influence the behaviour of Klipper macros, which is more or less the core functionality of variables. Calling them “meta” variables and slightly modifying how they’re accessed would not fundamentally change anything about them, just introduce confusion as to why there are now two different variable systems.

ignore_min_extrude_temp is maybe a little hackier because it’s never used by a macro and is purely an annotation used by an external tool, but it still seems like a very reasonable thing to do.