It was not me who brought it up and I agree. Let’s focus on Home-Assistant to not support YAML on new integrations.
Yes you did, you said you were removing HACS support as protest about partial yaml deprecation.
I linked Twitter with my opinion. 99% on that tweet is about why I think deprecating YAML on official integrations is a bad decision and powered by NabuCasa interests. From that tweet, you cherry picked the part about me deprecating HACS and, instead of replying on Twitter, copied that fragment to this post.
In any case, can we focus on the topic at hand around the deprecation of YAML for new integrations? (and probably in the past ones at some point, since you cannot also make changes to the YAML config and if the spec changes, YAML configuration would no longer work).
1 Like
It has been discussed to death. The decision is done, for better or worse, so your protests, like the others (including me), will fall on deaf ears.
Given that it is a done deal, either you want to work with home assistant or you don’t. If you don’t, then I suggest you get an interest in procreation and travel.
1 Like
That was a smooth change in topic, but at least back to the original and ‘productive’ one 
It has been discussed to death. The decision is done, for better or worse, so your protests, like the others (including me), will fall on deaf ears.
Yet, you’re still replying and replying to my posts. If you really do not care, there is no need for you to engage. You do not need to reply. It would best for both
If you are wrong and someone cares, they will engage. If you are right and no one cares, then there’s nothing for you to worry.
Given that it is a done deal, either you want to work with home assistant or you don’t. If you don’t, then I suggest you get an interest in procreation and travel.
I think there are more options than this. My post was asking and trying to be productive on that:
However, my question would be: when the decision is implemented, what can we do? I have some ideas and I will be sharing some of them soon both focused on users and developers. I would love to read some of your ideas too.
I do have some ideas and I am working on a small post that I will be sharing when ready. I hope those who care will engage, but so far I’ve only encountered people deviating from productive conversations or even from the main purpose of this conversation.
2 Likes
For those interested in the “cost of maintenance”, this is how much it took me to add support to the PS4 component:
Config = collections.namedtuple(
'Config', f'{const.CONF_ENTRY_ID} {const.CONF_DATA}')
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
Although, of course, this assumes you already have the token. However, the same config_flow could provide that for you to configure as many other components do. I will be publishing a full example when completed.
It might work but its not an acceptable implementation since you go to async_setup_entry directly
Can you explain further on what’s wrong with it and/or how to fix it?
Do note that the full code is not here, I am working on a component based on this. However, happy to tackle any issues that there might exist.
1 Like
You need to create a config entry in order to use async_setup_entry. You need to create a config flow with an import step that can be called in async_setup
I do not think so.
async_setup_platform works with configuration.yaml and does not require that. Do note that ps4_media_player.async_setup_entry is the core ps4 component. However, this all just python functions and classes, and you can pass your own configuration instead of rely on Home-Assistant.
Yes, to keep the original flow with async_setup_entry, I need to have the config flow. A few notes:
- If that code was added to the original repository, the rest of function falls into place.
- The purpose of this code is a
custom_componentthat addsconfiguration.yaml, so not having support for the UI wouldn’t be a problem. If that’s what you want, the core component is your option. - Now, I was able to support both. As I said, the code is not complete, but you can add support like this:
@config_entries.HANDLERS.register(const.DOMAIN)
class PlayStation4FlowHandler(config_flow.PlayStation4FlowHandler):
def __init__(self):
super().__init__()
It might work but I’m telling you its a requirement. Config entry to use async_setup_entry. I don’t see arguing for it working in a thread that is focusing on official content. You can do whatever you like with custom components 
A requirement set by? The people who dropped support for YAML configuration on integrations or Python language? Since it works, I’m assuming it’s not the latter.
1 Like
What does the python language have anything to do with your suggestion or this thread?
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).
1 Like
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? 
Of course it is easy when you disregard all the guidelines, I don’t think that’s anything to dispute
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:
- MQTT Light, MQTT Vacuum, and others under MQTT; use virtually the same code.
- the demo climate, and all the other demos, do the same approach but in viceversa.
-
met weather uses a hybrid approach where
async_setup_platformmassages 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.
2 Likes
I didn’t know that.
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.
Now that is simply not true.
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.
10 Likes