esphome / esphome/backlog

Use dependencies to set order of component creation and setup

Open
#56 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

The order of component creation (pointer variables generated into main.cpp) and runtime `setup()` calls is important. Currently this is managed by assigning arbitrary priorities via `@coroutine_with_priority` (for build-time creation) and the runtime `get_setup_priority()` for `setup()`.

There are several issues with this;

* No detection of circular dependencies
* Knowing what priority to assign requires knowledge of what priorities are used by other components
* Easy to overlook setup priority when building new components
* The coroutine model is non-deterministic - successive builds from unchanged yaml routinely produce different orders of component creation.
* Runtime startup has to sort components by priority
* Runtime setup() calls can only be done in strict order, potentially introducing unnecessary delay
* Some code overhead with the overriding `get_setup_priority()` methods.

Proposal:

* At build time create a dependency graph based on the `DEPENDENCIES` and `AUTO_LOAD` already provided by components, augmented by required fixed dependencies, such as having all components depend on `logger` if it is configured.
* From this graph create a topological sort, plus some fixed relationship, e.g. name, to ensure determinism.
* In the sort creation any circular dependencies will be detected.
* Run component build in that order
* Emit the component list in sorted order for the runtime startup to use to process `setup()` calls rather than sorting at runtime.
* Remove the `get_setup_priority()` method.

Questions:

1. Is the desired construction order always the same as the desired `setup()` order? Probably yes, but needs review.

Possible additional features:

With respect to #38 the impact of delays during `setup()` could be mitigated if the runtime startup had the dependency graph rather than a simple sort order, so could proceed with `setup()` calls that did not depend on a component that was blocking progress with `can_proceed()`.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.