This configuration:
homeassistant:
packages: !include_dir_named packages
works great to include package files because all the packages files look the same – you can cut-n-paste between packages since all keys are at the same level. You can also copy-n-paste from configuraton.yaml.
The one problem with this is the keys that !include_dir_named uses are the basename stem of the files, and so that prevents (in a very un-unixy way) duplicate file names.
That is with these two packages:
packages/irrigation/monitoring.yaml
packages/solar_power/monitoring.yaml
one of those files is silently ignored w/o reporting an error. That feels like a bug.
(Yes, I’m aware of !include_dir_merge_named and using a unique top-level key in each file.)
I’m not quite clear on the point of the package name keys. Are they used other than just reporting errors like this?
frankly, I’d rather see the full path to the file than the stem of the filename.
Is there a reason !include_dir_named (as above) couldn’t effectively generate:
homeassistant:
packages:
irrigation_monitoring: !include packages/irrigation/monitoring.yaml
solar_power_monitoring: !include packages/solar_power/monitoring.yaml
to make the keys unique?
So, the question is would including the path segments in the key break anything?
Again, in the error messages I would rather have the path to the filename where the error is, so I’d be happy if there was another include type that simply does a deep merge of the dictionaries:
homeassistsant:
packages: !include_merged_path packages/
or even…
homeassistant:
packages:
my_packages: !include_merged_path packages/
other_packages: !include_merged_path other_location/
if I could reload individual packages by doing it that way.