The future of YAML

Blog
599

Keep up the great work.
I like the new front end and cleaner yaml files.
Helpers are awesome.
Now with more tasmota auto discovery options for sensors and switches it makes things even faster to integrate new devices.

1 Like
600

For those of you who are frustrated by this decision:

It seems a bit hard to change the decision that has been made and the owners of the repository can (unfortunately) take such decision. Thereā€™s a bit of evil on the good, and a bit of good in the evil.

Like many of you, I have also expressed my opinion on why I do not think this is the right decision from an Open Source perspective. Although many of you have articulated the reasons for which is a bad decision much better here.

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.

10 Likes
601

From your twatter thread

Personally, Iā€™ve taken down 2 published components, removed HACS support for one of them and cancelled other plans for components that I was building for home_assistant and their HACS support.

Childish? Yes

And what have you got against HACS?

2 Likes
602

Apparently HACS is an official custom integration. :man_shrugging:

603

Itā€™s not.

My first idea was to completely remove the integrations, which I did consider and did with some of them.

I finally decided that having to copy the code was better than install it from a UI. Itā€™s kind of the opposite of what was decided on this blog post to force people to use UI for official integrations.

604

Thanks for sharing your opinion. You can read my previous message on why I want things to be installed only via code rather than via UI only.

(Actually, I would prefer both, but then the official integrations only offer one of them).

605

Removing your custom components from HACS is unrelated to this issue. Anything on HACS is installable via command line.

Also custom components do not have to be configurable by UI. They can stick to yaml. They wonā€™t ever make it to core, but that is not the point.

To be very clear, this thread is about the deprecation of core integrations to be configured by yaml.

1 Like
606

It was not me who brought it up and I agree. Letā€™s focus on Home-Assistant to not support YAML on new integrations.

607

Yes you did, you said you were removing HACS support as protest about partial yaml deprecation.

608

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
609

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
610

That was a smooth change in topic, but at least back to the original and ā€˜productiveā€™ one :wink:

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 :wink:

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
611

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.

612

It might work but its not an acceptable implementation since you go to async_setup_entry directly

613

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
614

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

615

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:

  1. If that code was added to the original repository, the rest of function falls into place.
  2. The purpose of this code is a custom_component that adds configuration.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.
  3. 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__()
616

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 :slight_smile:

617

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
618

What does the python language have anything to do with your suggestion or this thread?