My point is that adding those lines, one could configure PS4 component both via YAML and/or via UI. As you said, it works.
Yet, there’s a decision to deprecate YAML on the premise of cost of support.
Until there, where I am clear. Below what i’m trying to understand from your point:
You are also bringing a requirement which I haven’t read before, but it doesn’t seem a requirement of the Python language (which powers Home-Assistant components) and it doesn’t seem a requirement of the system itself. As you said it works. Hence, if this really is a requirement, it is an arbitrary one; most likely an imposed guideline to make YAML support harder (not like it’d be needed, since the change to add the support won’t be needed).
There is a dependency chain here; if you want a device, it depends on an entity being in the entity registry (unique id) and a config entry (config entry id). If you bypass the import you can’t get the config entry id. But I’m not interested in talking about the policies, I just wanted to state the fact that yes your code works but it doesn’t follow the guidelines for a integration to be accepted into the core repo. If you want to do stuff as custom components that fine but this thread about the future of yaml is not really relevant for custom components.
Entry id is a unique id, you can generate a uuid and pass it in the config. In my code, I simply pass the entity id. Do note that the objective is not to store this in .storage, so by default it goes against the policy and that was my point.
And yes, as stated, it’s for a custom component; so no problems. But to the point of the post, how hard would it really be to support YAML with a simple translation like the one I did?
Guidelines that could be changed since they are set by contributors like you.
This is not an anti pattern, it is a simple Adaptor Pattern that reads configuration.yaml and adapts the structure to the one in .storage. This allows to support YAML without any extra additional changes or cost of maintenance on the code base.
In any case, I am not saying it needs to be implemented exactly as how I am suggesting. However, the YAML structure and JSON are equivalent and one can be translated into the other one. That’s what I am advocating for.
To add to this, some official components are indeed using that technique today:
the demo climate, and all the other demos, do the same approach but in viceversa.
met weather uses a hybrid approach where async_setup_platform massages the data and then both setup methods delegate to the same common function. Relatively similar to cast media_player as well.
So it doesn’t seem like a crazy idea after all, and this is not even an extensive list. Additionally, reviewing a lot of the config_flow implementations what I have seen is virtually a copy/paste of the code from async_setup_platform to async_setup_entry. Hence, this could have been done in even more places if that was of your interest.
Another way to approach it: Your code has mechanisms to send the configuration from component to component. Conceptually, a similar principle can be used to delegate the configuration from async_setup_platform to async_setup_entry.
I have yet to hear how this code (or an improved version with the same approach) is bad, affects performance or it is hard to maintain; beyond not being your liking (i.e. disaligned with current guidelines). This only makes me think that the problem is not the cost of maintenance, but other interests.
For me personally it is a question of reasonable maintenance since a majority of issues and support cases was with helping people getting yaml config to work. It is much easier now with all configuration happening through the options flow.
When things go wrong there is pretty much nothing we can do to help because .storage is undocumented. With yaml it was simple to point out correctIons to misconfigurations.
How is it expensive to maintain this? Could you elaborate? Genuine question.
async def async_setup_platform(
hass, config, async_add_entities, discovery_info=None):
"""Loads configuration and delegates to official integration."""
# Load configuration.yaml
host = config.get(const.CONF_HOST)
name = config.get(const.CONF_NAME, const.DEFAULT_NAME)
region = config.get(const.CONF_REGION)
token = config.get(const.CONF_TOKEN)
# Format it in the new config_entry JSON format.
config_entry = Config(
util.slugify(name),
{
const.CONF_TOKEN: token,
const.CONF_DEVICES: [
{
const.CONF_HOST: host,
const.CONF_NAME: name,
const.CONF_REGION: region,
},
],
}
)
await ps4_media_player.async_setup_entry(
hass, config_entry, async_add_entities)
return True
It is literally getting the config and changing the structure into what async_setup_entry. It is definitely much less costly than this async_migrate_entry that it is today needed to avoid breaking the system among changes in syntax.
UI First
I 100% agree! Let’s make it UI first. Let’s make sure that everything works in the UI, please.
Now, let’s make it like Lovelace dashboards. Do you want to “edit manually”? At your own risk, expect the system to break, expect lesser support for you and more problems.
However, do you see benefits on it? Let me enable you to use YAML!
Cost of Maintenance
Let’s also make configuration.yaml optional to avoid burden on those who don’t want to implement it. Let’s not add burden to people.
However, a contributor wants to add a simple fix like the Adapter Pattern above? Let’s encourage it!
It’s the best of both, not either or that we are asking for.
That’s a good solution. It is harder to implement centrally as the translations may not map 1:1; but if they do, then it’s definitely doable and one of the solutions. Doing it per solution can bring a bit more of nuances into it, but both are possible.
Has any of this been considered during ADR-0010? Can it be considered and discussed?
I am happy to continue the discussions in another post, if we are not allowed to discuss ADR-0010 on the community/blog post about it. However, I wanted to make clear that these were not unrelated to the main thread or related to custom components; but actual arguments to the main discussion here.
I have also submitted another one with a potential solution which advocates for reusing the same schema, set up and partially rely on UI to solve most or all of the problems with the “cost of maintenance”.
There are also alternative proposals. If you have your ideas, you should also feel encouraged to bring them.
Harmony (example) still supports YAML as per documentation and code. I have not seen any notifications on my system that this is deprecated or the entity has been migrated.
However, YAML changes will no longer reflect on the system. I’ve done the following test:
Restarted system, for YAML configuration to update.
UI still shows 0.4.
As per my discussions with OnFreund, this seems to mean that my entities have been ported from YAML to UI. However, I do not think I have received any notification on my system about it; and, as stated, this component still supports YAML.
If I was a user who do not check Blog or Community, how was I supposed to pick this up?
This feels broken and not working as intended. Can someone else replicate this?
You understand that the UI and Yaml are separate configurations correct? I.E. UI does not impact yaml and yaml does not impact UI. You as a user choose one or the other, not both.
Now, I have never configured Harmony on the UI, or clicked any migrations. My configuration is solely YAML.
Additionally, Harmony still has configuration available for YAML, as you have happily copied from the documentation.
As such, why do I have the UI if “yaml does not impact UI”? The entity was migrated from YAML to UI without my changes. At the moment, I have my configuration.yaml where I still have my configuration, but this configuration is useless. I do not have any messages telling me or confirming that my entities have been migrated.
