We shouldn't rely on `git diff`. Even when the underlying source code
hasn't changed, and the cache is dumped with `sort_keys=True`, some of
the generated snippets of docstrings may change, leading the CI/CD
pipeline to get stuck in a push loop.
We should instead look for changes to the plugins, backends, events and
schemas folders before and after the CI/CD trigger to infer if we need
to regenerate the file.
Reason: The CI/CD automation regenerates the cache file, and commits
the changes if it differs from the previous version.
The only way to ensure semantic equivalence is to sort the keys upon
dump.
The cache is no longer generated at runtime when the application runs -
which may take quite a while, especially on fresh installations.
A `components.json.gz` file is instead generated by the CI/CD process on
every commit to the main branch, and distributed with the package.
The application will read this file when the `inspect` plugin is first
initialized.
This also means that we can no longer cache the `install_cmds`, as they
change depending on the target OS. A new
`application.get_install_commands` action has now been made available to
the UI, so it can get the correct installation commands at runtime.
Instead of loading all the tracks in the DOM (very inefficient and slow
on slow devices and/or with big playlists), we should keep a window of
100 items in the screen and roll it over the playlists as the status
change or the user scrolls.
- Fixed regression introduced by incorrect format string in `exec`.
- LINT for the `procedure` module.
- Apply `Message.Encoder` when dumping values from the context.