* Cache serialize of manifest for loaded integrations
The manifest/list and manifest/get websocket apis
are called frequently when moving around in the UI.
Since the manifest does not change we can make
the the serialized version a cached property
* reduce
* reduce
* Fix memory leak when importing a platform fails
re-raising ImportError would trigger a memory leak
* fixes, coverage
* Apply suggestions from code review
* 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
