BadAppConfig during Reading user apps due to list variable trying to be parsed as app
What happened?
My yaml apps started failing yesterday (was working before) due to a yaml list variable being treated as an app and not being able to parse it.
Add on version: 0.17.2 AD version: 4.5.3
Version
4.5.3
Installation type
Home Assistant add-on
Relevant log output
# Error
===== Reading user apps =================================================
BadAppConfigFile: /homeassistant/appdaemon/apps/apps.yaml
BadAppConfig: The key/value pair of all_modules=['some_module', 'other_module', '...'] is not valid
===========================================================================
Relevant code in the app or config file that caused the issue
# apps.yaml
my_1_module:
global: true
module: my_1
my_2_module:
global: true
module: my_2
all_modules: &all_modules
- my_1_module
- my_2_module
app_1_handler:
module: app_1_handler
class: App1Handler
dependencies: *all_modules
log: some_log
app_2_handler:
module: app_2_handler
class: App1Handler
dependencies: *all_modules
log: some_other_log
Anything else?
No response
Hi there - the issue here is that we recently added validation to apps.yaml and other files, and this is not a correctly formed apps.yaml - we never actually supported this kind of usage (although we probably just ignored it).
So, what are you trying to achieve here? Maybe there is another way you can do this.
My AD module inter-dependency is quite complicated, so I basically want all apps to reload on any module changes.
To achieve this I made a helper yaml variable that contains all of my modules and then have the individual apps depend on it. This way when I add new modules I add them to that list without having to figure out that an app depends on a downstream module.
e.g. app1 -> module_a -> module_b -> module_c so that changes to module_c reloads app1.
Also if I have app2 that also depends on module_a, I don't want to have the duplicated chain of moduels.
In yaml *all_modules references &all_modules and uses it.
OK, makes sense - we will look into a way we can accommodate that with the new dependency backend (the dependencies piece has also been completely re-written so this would likely not work even if we allowed it in the YAML).
If you want to get things working immediately you will need to remove that dependency list section.
@jsl - maybe we can add a switch or directive to disable the dependency checking and just reload everything for any change?
OK, makes sense - we will look into a way we can accommodate that with the new dependency backend (the dependencies piece has also been completely re-written so this would likely not work even if we allowed it in the YAML).
If you want to get things working immediately you will need to remove that dependency list section.
@jsl - maybe we can add a switch or directive to disable the dependency checking and just reload everything for any change?
Pinging @jsl12 by proxy 😉
ahh sorry, wrong jsl!
I can look into some kind of reload switch that would force everything to reload, but I think it's probably unnecessary.
Can you elaborate a little more about your dependencies? Are they caused by modules importing each other? The new system might be able to automatically handle them
This issue is stale because it has been open for 6 months with no activity. Remove stale label or comment or this will be closed in 15 days.