tech/node groups to templates

[brynpickering]

Fixes #600

I've merged tech_ and node_ into templates as there's no real reason to split them. You can access the same template from techs or nodes but the chance that it causes issues is minimal. The benefit is fewer top-level keys.

I've kept the reference to "inheriting" templates in the docs and the helper function. If there is a perference to purge all concept of inheritance, we could change it, but I don't have a good idea what to replace it with.

Summary of changes in this pull request

• tech_groups/node_groups -> templates
• inherit -> template

Reviewer checklist

• Test(s) added to cover contribution
• Documentation updated
• Changelog updated
• Coverage maintained or improved

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.97%. Comparing base (2099815) to head (b063029).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #655      +/-   ##
==========================================
- Coverage   95.98%   95.97%   -0.01%     
==========================================
  Files          26       26              
  Lines        3981     3980       -1     
  Branches      836      767      -69     
==========================================
- Hits         3821     3820       -1     
  Misses         70       70              
  Partials       90       90              

Files with missing lines	Coverage Δ
src/calliope/backend/helper_functions.py	96.84% <ø> (ø)
src/calliope/preprocess/model_data.py	100.00% <100.00%> (ø)

[irm-codebase]

I must say: I love this change. Very simple to understand, and will lead to users handling less terminology.

Bryn's idea to just merge everything into templates is excellent.

[irm-codebase]

The new name is excellent!
Very easy to follow what's happening now!

[irm-codebase]

Small note: generally I think it's ok to omit long parameter explanations if they are in the docstring body above. Keeps docs lean and leads to less boilerplate fixing over time.

[irm-codebase]

The red mark above indicates that the document does not end in an empty line. Generally, it's good to do so to aid in machine readability.

I'll fix that in a PR soon through pre-commit CI

[irm-codebase]

Nice-to-have: consider adding the small docstring to the modified tests, so that we know what they do in the future.

Feel free to skip.

[irm-codebase]

Excellent!

[brynpickering]

@sjpfenninger @irm-codebase one thing I missed is that you still end up with the two input variables in the xarray dataset: techs_inheritance and nodes_inheritance. For techs/nodes, they define the inheritance chain that was used to create that tech/node's definition. They need to be separated as they are indexed only over their respective dimensions. Should these be tech_templates and node_templates, or does inheritance make sense here?

[irm-codebase]

@brynpickering looking at the code, it seems they achieve very similar things, but I do not think they match template's purpose, since template is more of a 'user-side' thing, and this seems more 'internal'...

I think you are right in just going for inheritance.

[sjpfenninger]

Suggested change

	??? info "Sharing configuration through inheritance"
	??? info "Sharing configuration through inheritance from templates"

[sjpfenninger]

@sjpfenninger @irm-codebase one thing I missed is that you still end up with the two input variables in the xarray dataset: techs_inheritance and nodes_inheritance. For techs/nodes, they define the inheritance chain that was used to create that tech/node's definition. They need to be separated as they are indexed only over their respective dimensions. Should these be tech_templates and node_templates, or does inheritance make sense here?

I agree with @irm-codebase that we can stick to inheritance here which marks this as a separate (but related) variable.