Co-authored-by: Sid <27780930+autinerd@users.noreply.github.com>
Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
Co-authored-by: J. Nick Koston <nick@koston.org>
* Refactor setup time tracking to exclude time waiting on other operations
We now exclude the import time and th time waiting on
base platforms to setup from the setup times
* tweak
* tweak
* tweak
* tweak
* adjust
* fixes
* fixes
* preen
* preen
* tweak
* tweak
* adjust
* tweak
* reduce
* do not count integrtion platforms against their parent integration
* handle legacy tts platforms
* stt as well
* one more wait
* use the same pattern in all the legacy
* fix tts and stt legacy
* fix
* fix
* reduce
* preen
* entity comp does not wait for platforms
* scene blocks as well
* fix test
* test fixes
* coverage
* coverage
* coverage
* fix test
* Update tests/test_setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update tests/test_setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update homeassistant/setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* strip
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* remove complexity
* Apply suggestions from code review
* no longer works that way
* fixes
* fixes
* fixes
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Avoid pre-importing config_flows if the integration does support migration
Currently we pre-import the config flow module if it exists since
setting up the config entry required comparing the versions found
in the config_flow.py. We can avoid the pre-import if the integration
does not support async_migrate_entry which means we avoid loading
many config flows in memory at startup.
* cover
* fix missing block
* do not call directly
* its too fast now, the test gets more along
* Update homeassistant/loader.py
We previously checked Integration.config_flow to see if we should
pre-import the config flow, but this is now always set for some
integration like `homeassistant_green`, `hassio`, etc. Instead
we can add it to the rest of the platforms since we already know
which files exist. This simplifies the logic and ensures the pre-import
still happens if the file is there even if its not listed in the
manifest
`2024-03-04 22:54:31.906 DEBUG (MainThread) [homeassistant.loader] Importing platforms for homeassistant_green executor=[config_flow] loop=[] took 2.74s`
* Migrate remaining calls in config modules to async_get_component
There were a few cases that were still using get_component that
could have done blocking I/O in the event loop, although it
was unlikely.
The caching check in async_get_component has been moved
up to avoid creating the future if the module is already in
the cache
* fix one more
* Import in the executor by default for core integration
* merge correct branch in
* Group loading of platforms in the import executor
* adjust test
* remove other pr
* Fix async_prepare_setup_platform test
The message changed because the order changed but was not caught before
merge because it required the combination of PRs to change
the error message
* fix
* tweak
* fix
* self review
* review
* fix hue mocking
* Update homeassistant/loader.py
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* lint
* Fix async_get_component loading in the executor when the module is already loaded
The sys.modules check was incorrect (only on dev)
* fix
* Avoid multiple executor jobs with concurrent calls to async_get_component
Return a future that can be awaited if the component is
curently being loaded
* adjust
* coverage
* coverage
* concurrent platforms load test
* doc strings
* coverage
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
Since config_entries always requires the config_flow to be loaded
to check for migrations, load it if we know it exists when loading
the underlying integration
* Avoid trying to import platforms that do not exist
* adjust
* fixes
* cleanup
* cleanup
* cleanup
* Apply suggestions from code review
* docs
* fixes
* fixes
* comment
* coverage
* coverage
* coverage
* Switch config to use async_get_component
This was another path where integrations that were marked to load in the executor
would be loaded in the loop
* Switch config to use async_get_component/async_get_platform
This was another path where integrations that were marked to load in the executor
would be loaded in the loop
* merge
* refactor
* refactor
* coverage
* preen
* preen
* Deprecate @bind_hass and log error if used inside custom component
* Log also when accessing `hass.components`
* Log warning only when `hass.components` is used
* Change version
* Process code review
* Add support for pre-imports at setup time
alternative solution to #111331
* refactor
* refactor
* refactor
* mark >1.0s integrations
* no point in executor if already loaded
* no point in executor if already loaded
* cleanup
* cleanup
* two more
* one more
* analytics loads a lot more integrations
* cloud
* debug
* psutil, hardwre
* try zha
* Update homeassistant/setup.py
* await
* comments
* coverage
* coverage
* coverage
* move logic to loader
* move logic to loader
* preserve comments
* Allow setting if we support multiple config entries in config flow
* Move property to config flow instead of flow handler
* Move marking an integration as single instance only to manifest
* Revert line remove
* Avoid init a config flow or adding a new entry on a single instance with an entry
* Revert changes in test
* Process code review comments
* Apply code review suggestion
* Move late import of config flows in loader to load time
There does not seem to be any reason to import the
generated flows late. Import them at load time
with the rest of the generated files
* tests
* Small performance improvements to config entry setup retry
- cache some properties that never change
- avoid loader.async_get_integration when we already have it
- avoid multiple integration.domain checks
* tweaks
* Fix _async_component_dependencies
Fix bug with circular dependency detection
Fix bug with circular after_dependency detection
Simplify interface and make the code more readable
* Implement review feedback
* Pass all conflicting deps to Exception
* Change inner docstring
Co-authored-by: Erik Montnemery <erik@montnemery.com>
---------
Co-authored-by: Erik Montnemery <erik@montnemery.com>
We should have been checking for the module in hass.data[DATA_COMPONENTS]
and not hass.config.components as the check was ineffective if there were
no existing integrations instances for the domain which is the case for
discovery or when the integration is ignored
Joost Lekkerkerker
J. Nick Koston
Sid
G Johansson
Paulus Schoutsen
Marc Mueller
Erik Montnemery
Jan-Philipp Benecke
Joakim Plate
Aarni Koskela
Artur Pragacz