Skip to content

Conversation

@maxwhitemet
Copy link
Contributor

@maxwhitemet maxwhitemet commented Mar 27, 2025

Addresses #866

Description

  • Updated plugin and CLI to accept a JSON file
  • Associated JSON file for tests available here

Testing:

  • Ran tests and they passed OK
  • Added new tests for the new feature(s)

@maxwhitemet maxwhitemet requested a review from brhooper March 27, 2025 15:53
@codecov
Copy link

codecov bot commented Mar 27, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (84a8944) to head (6b6d2bf).
⚠️ Report is 156 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2114      +/-   ##
==========================================
+ Coverage   98.39%   98.46%   +0.07%     
==========================================
  Files         124      139      +15     
  Lines       12212    13777    +1565     
==========================================
+ Hits        12016    13566    +1550     
- Misses        196      211      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@brhooper brhooper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @maxwhitemet. I've added some suggestions, the mains ones being around changing the format of the json file to simplify the unnecessary "threshold: None" format.

@brhooper brhooper assigned maxwhitemet and unassigned brhooper Apr 4, 2025
@maxwhitemet
Copy link
Contributor Author

Thank you for the review @brhooper. I have implemented all of the suggested changes.

@maxwhitemet maxwhitemet assigned brhooper and unassigned maxwhitemet Apr 7, 2025
Copy link
Contributor

@brhooper brhooper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @maxwhitemet, I've added some comments.

self,
threshold_values: Optional[List[float]] = None,
threshold_config: Optional[Dict[str, Union[List[float], str]]] = None,
threshold_config: Optional[Union[List[float], Dict[str, str]]] = None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
threshold_config: Optional[Union[List[float], Dict[str, str]]] = None,
threshold_config: Optional[Union[List[float]], Dict[str, Union[List[float], str]]] = None,

I can't work out why this was changed, so if I've missed something then please let me know. I think the typing only needed the addition of Union[List[float]], ... though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


Original annotation
The original annotation comes from the threshold.py plugin and suggests dictionary values can be either a list of fuzzy bound floats or a "None" string.

Annotation I suggested
My annotation suggests that if a dictionary is provided, the dictionary's values can only be a "None" string. We don't use fuzzy bounds for threshold interpolation.

I have kept my original change for now. Please let me know if I have misunderstood something

threshold_values: Optional[Union[float, List[float]]],
threshold_config: Optional[dict],
threshold_values: Optional[List[float]] = None,
threshold_config: Optional[Union[List[float], Dict[str, str]]] = None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
threshold_config: Optional[Union[List[float], Dict[str, str]]] = None,
threshold_config: Optional[Union[List[float]], Dict[str, Union[List[float], str]]] = None,

Same suggestion as above - sorry if I've missed something.

@brhooper brhooper assigned maxwhitemet and unassigned brhooper Apr 8, 2025
@maxwhitemet maxwhitemet assigned maxwhitemet and Kat-90 and unassigned maxwhitemet Apr 11, 2025
@Kat-90 Kat-90 added the Paused label Apr 23, 2025
Copy link
Contributor

@Kat-90 Kat-90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Max.
Your PR description needs fleshing out a bit as you've changed more than just adding a JSON input now.

My tests fail the checksums as well so you might need to update them and repush.
I've left a comment on your test_data PR as well: #2114

@bayliffe bayliffe assigned maxwhitemet and unassigned Kat-90 May 28, 2025
@bayliffe bayliffe removed the Paused label May 28, 2025
@cpelley
Copy link
Contributor

cpelley commented May 28, 2025

Looking at your type hints, seems to me that the improvers json input functionality exposes its limited deserialisation capability (internal technical implementation detail) to functions that need to use it.

I would expect null to be used within a json to allow built-in deserialisation to a Python None and keys that represent a string of floats or ints to be converted appropriately by improvers deserialisation capability.

json containing:

{
    "1.5": [2.0, 3.0],
    "2.0": null
}

These input dictionaries to these functions should be considered dictionaries containing the expected types, not those representing types characterising the spec of json.

I would expect the above json to be deserialised appropriately to the following python dictionary:

{
    1.5: [2.0, 3.0],
    2.0: None
}

In future, we will want to be removing the clize layer. I don't think it ideal for functions to individually handle/be exposed the deserialisation limitations of improver json loading. This unnecessarily binds the two layers together.

Not a blocker for this PR of course, this wasn't due to your changes, I just noticed as your changes drew attention to this issue.


Note: the above is conjecture right now, purely from reasoning your type hints, not by looking at improver json input loading capability or testing it.

* Changed plugin's functionality when new thresholds have different units such that the output cube's thresholds are converted back to the units of the input cube.
…imension from also modifying the cube's overall units.

* Implemeneted new variables in the cli call and created appropriate tests
@maxwhitemet maxwhitemet force-pushed the add_JSON_file_input_to_threshold_interpolation branch from 7587361 to 6b6d2bf Compare May 28, 2025 12:05
@maxwhitemet maxwhitemet assigned Kat-90 and unassigned maxwhitemet May 28, 2025
Copy link
Contributor

@Kat-90 Kat-90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When reviewing the suite ticket I noticed there is no redundancy for passing a config file into threshold_values, or a value list into threshold_config. This should probably be handled here or we should change the inputs to just accept "thresholds" for which the format is then handled within the plugin itself and the user doesn't need to choose which they think they should use.

@Kat-90 Kat-90 marked this pull request as draft May 30, 2025 09:04
@github-actions
Copy link

In order to maintain a backlog of relevant PRs, we automatically label them as stale after 60 days of inactivity.

If this PR is still important to you, then please comment on this PR and the stale label will be removed.

Otherwise this PR will be automatically closed in 30 days time.

@github-actions
Copy link

github-actions bot commented Oct 7, 2025

In order to maintain a backlog of relevant PRs, we automatically label them as stale after 60 days of inactivity.

If this PR is still important to you, then please comment on this PR and the stale label will be removed.

Otherwise this PR will be automatically closed in 30 days time.

@github-actions github-actions bot added Stale and removed Stale labels Oct 7, 2025
@github-actions
Copy link

In order to maintain a backlog of relevant PRs, we automatically label them as stale after 60 days of inactivity.

If this PR is still important to you, then please comment on this PR and the stale label will be removed.

Otherwise this PR will be automatically closed in 30 days time.

@github-actions github-actions bot added the Stale label Dec 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants