Proposal: More default custom entry points for scripts

[justparking]

I am proposing Nodel supports more default custom entry points. It is an extension of #126.

The rationale behind this is improved file management when dealing with custom extensions or standard "bolt on" functionality to existing recipes.

As per that issue, nodeConfig.json can hold a list of scripting "dependencies", e.g.

{
    "dependencies": [ "script.py", "custom.py"],
    "remoteBindingValues": {
        "actions": ...
        "events": ...
    },
    "paramValues": ...
}

It defaults to [ "script.py", "custom.py"] if missing but it would be useful if it supported more defaults like these possible options:

1. It looks up all scripts named custom_XXXX.py (or XXXX_custom.py), e.g.
   • custom_SpecialStatus.py - e.g. add additional status handling
   • custom_IssueTracking.py - e.g. add a custom issue tracking module
   • custom_MySchedule.py - e.g. add some special scheduling

(they'd be executed in natural alphabetical order)

2. A folder is used, say named custom, to hold a bunch of scripts:
   • custom/specialStatus.py
   • custom/issueTracking.py (*) This could be considered an Ingredient
   • custom/mySchedule.py

(*) While we're at it, it might be a good time to make more use of the term Ingredients where we can keep standardised module/libraries/scripts, etc.

So just like custom_XXXX.py, ingredients (e.g. ingredient_XXXX.py) can be treated in a similar way.

So the rule would be:

1. load script.py
2. load all Ingredient scripts.
3. load all Custom scripts

[justparking]

Hey @scroix @paxofsnax @jordonrandall @mcartmel, if you have any thoughts on this proposal, feedback and opinions welcome!

[scroix]

I'm a fan of this idea.

I started using these quite extensively in order to add additional functionality onto beefy and complex nodes, without disrupting their primary functions -- in much the same way as you've described taking-on additional "ingredients" 🍎 🍌 .

For example (this is a real life private recipe):

├── script.py
├── config.py (imported module with instance specific references)
├── utilities.py (imported series of utility classes without utilising toolkit)
├── test.py (unit tests for above utility classes)
├── solar.py (nodeConfig loaded additional functions)
├── sensors.py (nodeConfig loaded additional functions)
└── prediction.py (nodeConfig loaded additional functions)

The only trouble I've found is due to my preferences for version control. I never commit the nodeConfig.json of a project, as I often maintain alternative bindings on my local machine vs. production.

It feels like an incomplete/hidden feature (but of course, still very useful) to manually edit the JSON to have additional scripts recognised. Both of your suggestions would solve the issue I've described above.

I'm fond of parsing a sub-folder. I think both names should be valid, but have a preference for ./ingredients which feels less generic in it's description, and a sub-folder named ./custom has already been used in the past to skin nodes (advscheduler, xmv amplifier).

👍

[justparking]

ingredient___.py and custom___.py will be loaded in that order.

NOTE: there is no functional difference between ingredient___.py and custom___.py files except for the former ones are loaded before the latter ones.

Use of directories was avoided as it it'd still require the use of prefixes anyway and perhaps cause confusion.

The config.dependencies parameter of nodeConfig.json is still respected.