Config System

[leshy]

• each module receives both global settings and module based settings
• subclassable, my_detector_module can subclass detector_module config and it's defaults
• defaults/module config defined per module in module
• typed, with automatic conversion (e.g. if I pass --mujoco-start-point '3.1 4.5' it should set the list [3.1, 4.5])
• pydantic or dataclasses?
• be able to have a local overrides file (e.g. like .env currently, but should be pluggable, .json overlay .yaml overlay stuff like this)
• be able to override each setting in a command line option
• easy way to see what the actual config of a blueprint is (get config from each module in the blueprint, assemble global yaml/json with values)
• after I import global config from somewhere from dimos.core.global_config import GlobalConfig this already parsed everything (cli args etc) - since atm this is just a defaults dict modified dynamically by cli tooling

overlay example, multiple systems overlaying into the same config tree

base_config -> json dir -> env vars

I have my base config

camera:
   fps: 30
   dev: /dev/video0

I run the system with

CAMERA_FPS=44 dimos run ....
or
dimos run --camera-fps=44 ....

config is overlayed

camera:
   fps: 44
   dev: /dev/video0

we also want control over which overlays are used, like apply "mac" dir if mac is detected (to override transports etc)

[linear]

DIM-374

[leshy]

hydra seems to cover all of this
go through all tutorials - structured and basic

https://hydra.cc/docs/tutorials/basic/your_first_app/simple_cli/

[alexlin2]

It should be dynamically reconfigurable like the https://wiki.ros.org/dynamic_reconfigure/Tutorials/SettingUpDynamicReconfigureForANode%28python%29

[Kaweees]

Thoughts on using Tyro for command-line configuration?

[leshy]

Thoughts on using Tyro for command-line configuration?

Not against it on a brief look, I think hydra already does this as well, owner can think in detail and decide

It should be dynamically reconfigurable like the https://wiki.ros.org/dynamic_reconfigure/Tutorials/SettingUpDynamicReconfigureForANode%28python%29

can be done as a subsystem above for later, not for the first pass since lots to think about even without this

[jeff-hykin]

been meaning to say this on here, I think it would ideal for us to have an exposed API for global_config = create_config(argv, module_info, config_path).

Ex:

from dimos.somewhere import create_config

autoconnect(...).build(
    global_config=lambda mod_info: create_config(argv, mod_info), # still uses the config file but just auto-finds it
)

This lets library users re-use our arg parsing (which would help us make it a standard)

The lambda enables us to provide module-specific type checking of config values. E.g. people can configure a module's args from a config without loosing checks.