Extensions release

[barneydobson]

Issue to discuss finalisation of the new extensions ability.

Below copied from #99

Within #97 - @dalonsoa

• Create extensions_register
• Create register_node_method (optional arg for sub_object).
• Add apply_decorators
• Tests (make tests that can be used in docs)

Within this PR - @dalonsoa

• Implement sequence above
• Tests (make tests that can be used in docs)

Close #54 , make a new PR - @liuly12

• Keep the custom orchestration stuff, bin else

Enable custom subclasses

• Move load_extension_files to occur before add_nodes #108

Documentation (new issue)

• Overview of all new functionality (overrides, subclassing, decorators). - @dalonsoa #111
• Enable decoration of handlers (easy to code - a distinct decorator, e.g., register_node_handler) - us to revisit
• update documentation for 'customise interactions' and 'river reservoir'. @barneydobson #112
• Take down old documentation on customisation ('customise a node'). #113
• Release here! @dalonsoa
• Longer term issue to update customise a node.

[barneydobson]

@dalonsoa did we have a plan to add custom classes - I know it can be done by updating the registry but there's no way to enter those in the normal config use. You could add them to be loaded by load_extension_files - but this would need to take place before add_nodes since the subclasses will need to have been registered before that point

[dalonsoa]

I don't remember if we ditched the idea, or just forgot to include it in the plan above. In any case, it should be as simple as moving this line:

wsi/wsimod/orchestration/model.py

Line 223 in 61573a9

load_extension_files(data.get("extensions", []))

To before adding the nodes. The extensions files can have decorated stuff but also extra classes, so they all should be "registered" together. I don't think there's any reason for loading the extension files at the end rather than at the beginning.

[barneydobson]

I will add that to the list of tasks above

[barneydobson]

will be fixed by #127