Request to support nested packages (packages inside packages)

Feature Requests
1

It would be better if we can support packages inside packages in configuration. I have a use case where i want to include multiple packages which are similar to each other as a package like below.

File: configuration.yaml

    packages: !include packages/packages.yaml

File: packages/packages.yaml

    fans: !include fans/fans.yaml

File: packages/fans/fans.yaml

    packages:
      fan1: fan1/fan1.yaml
      fan2: fan2/fan2.yaml

File: packages/fans/fan1/fan1.yaml

    fan: ---
    script: !include scripts.yaml
    automation: !include automations.yaml

File: packages/fans/fan2/fan2.yaml

    fan: ---
    script: !include scripts.yaml
    automation: !include automations.yaml

This way i can copy paste fan directory make some changes and create a copy of the fan.

Let me know if i need to provide more details.

2

That would be really really messy.

You can already nest directories with the !include_dir_named so you can have

packages/
... /fans
...... /fan1.yaml
...... /fan2.yaml
... /climate
...... /climate.yaml
.../lights
...... /downstairs.yaml
...... /upstairs.yaml

The whole point of packages is that they’re a single file that contains all the parts you need for a given function.

3

Atleast in my case i was treating the packages as directory instead of just a single file. This allowed me to store the package information nicely in multiple files as it becomes difficult to manage a big file.

4

How many scripts and automations can you have for a single fan?

Edit - not to mention that you can still put the automations and scripts in separate files anyway, you just put the key at the top of the file instead of using an include from the previous file.

5

So you understand (as Marc said above) that you can include a whole directory (and any sub directories of that) with just one line ?

I assume you just wanted to avoid multiple inclusions and having to specifically name them ?
And you are happy that this request is not needed ?

6

I can have around ten - fifteen scripts for a single fan.

not to mention that you can still put the automations and scripts in separate files anyway, you just put the key at the top of the file instead of using an include from the previous file.
Can you please elaborate on this?

and one more quick question. Can we define script or automation key multiple times in a package like below?

script:
  script_fan1:
  ...



script:
  script_fan2:
    ...
7

Yeah, so

Filetree

packages/
..... fans/
.......... fan1/
............... fan.yaml
............... script.yaml
............... automation.yaml
.......... fan2/
............... fan.yaml
............... script.yaml
............... automation.yaml

Then fan1/fan.yaml

fan:
  platform: etc

fan1/automation.yaml

automation:
  alias: etc

fan1/script.yaml

script:
  etc:

fan2/fan.yaml

fan:
  platform: etc

fan2/automation.yaml

automation:
  alias: etc

fan2/script.yaml

script:
  etc:

And so on

8

Hi Mutt,
As far as i know i can only define automation and script key once. This will create conflict if multiple automation keys are defined for a single package.
Let me explain my current full configuration.
I have defined multiple packages in inside a packages.yaml like below.
File: configuration.yaml

packages: !include packages/packages.yaml

        packages/packages.yaml

 fans: !include fans/fans.yaml
 alarms: !include alarms/alarms.yaml

I like this organizational scheme because this way i can disable a single package like alarms by just commenting out the alarms line in packages.yaml Instead of deleted a whole set of files in case i would have used include_dir_merge_list which includes whole directories and sub-directories.

Can you please suggest a better way in which i can keep in organizational scheme, i which i want to keep each individual fan settings in its own folder (As explained in description of feature request) without the support of packages inside packages?

Thanks,
Robin Singh Nanda

9

Hi mf_social,
If i go with this organization scheme then i will lose the feature where i can disable the entire group like fan or fan1 by just disabling one line as explained in my comment to Mutt above. Please let me know in case you don’t understand it.

Thanks,
Robin Singh Nanda

10

Why?

configuration.yaml

homeassistant:
  packages: !include package_list.yaml

package_list.yaml

fan1: !include_dir_merge_named packages/fan1
fan2: !include_dir_merge_named packages/fan2
# fan3: !include_dir_merge_named packages/fan3
fan4: !include_dir_merge_named packages/fan4

== fans 1, 2 and 4 enabled, fan 3 disabled

11

May be i am really pushing here but we can’t disable all the fans directly. I wanted to expose the fans as package instead of individual fan as package.

Thanks,
Robin Singh Nanda

12

One more thing i failed to mention earlier that i like to keep the scripts and automation also in separate files like below.
packages/fans/fan1/scripts/script1.yaml
packages/fans/fan1/scripts/script2.yaml
packages/fans/fan1/automations/automation1.yaml
packages/fans/fan1/automations/automation2.yaml

I can’t do that if i use include_dir_merge_named.

-Robin

13

What you need to do is stop changing your mind on what you want…

I give up.

14

Sorry, i failed to explain my full problem in the description. Thank you much for your quick replies. You replies were really informative.

15

Usually people write packages because they describe a particular functionality, entity or usage case. ie they encapsulate a particular need of the person writting the package.
I’ve never seen people do it the way you describe and to be honest I dont see any benefit.
If I have a fans.yaml package then everything I need for the fans is in there.
Input booleans, switches, input numbers, input timedates, scripts and automations and even customisations. Because they all go together.
I do have a couple of packages with broader reach (light automations when I’m out, heating, occupancy, common lighting controls (brightness changes throughout the day).
If i need to ‘comment out’ an automation - i do just that
If I want to ‘temporarily’ remove a package - I just rename it to *.hold or something.

I obvoiusly don’t understand your need / usage as it makes no sense to me and probably not to most others which is why they are confused and why you have 0 votes as of todays date.

what am I not getting ?

16

Yeah ? still not getting it.
I just have an enable input boolean for each ‘fan’ in this case
You have to work with what’s available and I think (in this case) what is available is more than enough.

17

yes you can, i just explained that.
It means though (as you are an ‘outlier’ case) that you may have to do a bit more work.
But from this, I don’t think packages are for you

What editor do you use ?
If you use notepad++ or VBC then commenting 1 line is as easy as commenting out 100 and the reverse too.

18

Mutt,
I understand that we can do it by renaming the directory as .hold or something similar. Yes, it looks like my use case is outlier case. I can do all of this with the current implementation of the packages as well. Even i am doing that as now.
My understanding of a package was like packages in any other language like python where we can include a package inside a package or extend a package. Looks like that is not case in home assistant. packages in home assistant is more like single dimensional.
I use Configurator to edit my configurations.

Thanks,
Robin Singh Nanda

19

I will close this feature request as there is not much interest in request. My use case is probably a outlier case. Thanks you to mf_social and Mutt for help.

-Robin

20

No, not directory, the *.yaml file you wish to ignore

It took the devs a long time to get us from a monolithic architecture to the breakouts for automations, scripts, sensors etc and then on to packages.

Your analogy of a a single dimension array is a bit off as I consider it a single dimension array of single dimension arrays (containg everything else OTHER than more packages)

You can’t assume that every language has ALL the same features as ‘some other languague’ and that is the case here. I have to say that your choice (of python) is particularly appropriate as I consider python’s implementation of arrays ‘more than a bit lacking’

I hope you find a compromise that you are happy with but 99.9% of people are happy with the current implementation and your use/case is not even in the remaining 0.1%