Lfric macros update

[James Bruten (james-bruten-mo)]

PR Summary

Sci/Tech Reviewer: Cameron Bateman (@cameronbateman-mo)
Code Reviewer: Pierre Siddall (@Pierre-siddall)

This PR makes some general improvements to the lfric_macros repo:

• Use pathlib instead of os.path across all files
• Adds type hinting
• Adds a new check to check_macros_chain to check for rose-stem apps using older metadata than it should. This should prevent issues such as the one fixed in Bugfix for linear upgrade macro  lfric_apps#347

I've tested this locally with a new upgrade macro in lfric and made sure that it correctly raises failures when expected. A test release using release_new_versions has also been done.

Once this is on I'll open an apps ticket to update the scripts version.

Code Quality Checklist

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid understanding and enhance the readability of the code
• My changes generate no new warnings
• All automated checks in the CI pipeline have completed successfully

Testing

• This change has been tested appropriately (please describe)

Security Considerations

• I have reviewed my changes for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance of Generative AI tool name (e.g., Met Office Github Copilot Enterprise, Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the Simulation Systems AI policy (including attribution labels)

Sci/Tech Review

• I understand this area of code and the changes being added
• The proposed changes correspond to the pull request description
• Documentation is sufficient (do documentation papers need updating)
• Sufficient testing has been completed

(Please alert the code reviewer via a tag when you have approved the SR)

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• Code quality standards have been met
• Tests are adequate and have passed
• Security considerations have been addressed
• Performance impact is acceptable

[Cameron Bateman (cameronbateman-mo)]

I think this assert will always evaluate to true due to a tuple being involved, non-empty tuples are truthy.

[James Bruten (james-bruten-mo)]

You're right that non-empty tuples are truthy but this isn't actually a tuple. In python you need a trailing comma inside the () to denote a tuple. Here, the () are just showing that the assert is split over multiple lines for formatting purposes (done automatically by ruff)