Skip to content

Expose marine regions version - #83

Open
brynpickering wants to merge 2 commits into
modelblocks-org:mainfrom
brynpickering:expose_marineregions_version
Open

Expose marine regions version#83
brynpickering wants to merge 2 commits into
modelblocks-org:mainfrom
brynpickering:expose_marineregions_version

Conversation

@brynpickering

@brynpickering brynpickering commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Closes #82

Open Q: do we want to label output files with this version as we do with some of the others? It's unnecessary right now as we limit it to a single version.

Reviewer checklist

  • There are no pip dependencies in the module's environment files (workflow/envs/).
  • All rules use pathvars (e.g., <results>) in their inputs and outputs.
  • The integration test-suite is successful, including:
    • pre-commit.ci tests pass.
    • tests pass for all relevant OS configurations (linux, osx, windows).
  • Module documentation is up-to-date, including:
    • INTERFACE.yaml mentions all relevant pathvars and wildcards.
    • README.md describes how to use the module and has the necessary citations.

@irm-codebase

Copy link
Copy Markdown
Collaborator

Thanks for the submission @brynpickering!
To maintain the principle of re-usability of 'harmonised' files, I'd say it's a good idea to label them with the requested version, yeah.

@irm-codebase irm-codebase left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Looks good overall!

Only thing I suggest is moving from a 'hard cap' (version==2.0.0) to a more permissive 'lower cap' (version >= 2.x.x). This allows us and users to try updating the EEZ version without needing to update the module version.

Comment on lines 14 to 16
logs="resources/module/logs",
resources="resources/module/resources",
resources=temp("resources/module/resources"),
results="resources/module/results",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I did not know you could pass temp() outside the call!
Does it work?

lambda mrgid: "_".join([country_id, "marineregions", str(mrgid)])
),
"country_id": country_id,
"shape_class": "maritime",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

For future proofing, we should follow this approach:

  • known supported versions just call the expected process.
  • versions lower than the lowest major release supported raise the RuntimeError
  • versions higher throw a warning via warnings.warn (which will go to the log file) and call the latest version (so just 2.0.0).

Comment on lines +248 to +253
marine_regions_release:
description: |
MarineRegions WFS version to use to access EEZ data.
type: string
default: "2.0.0"
enum: ["2.0.0"]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

If my suggestions are implemented, we should replace 'enum' with a regex check based on this suggestion: semver/semver.org#431 (comment)

@irm-codebase irm-codebase Aug 5, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Basically, we handle semver checks in code and no not 'hard cap' them, so if EEZ 2.0.1 is released correcting just a couple of things but keeping the schema the same, we have no updates needed on our side. The schema just ensures that the string is an actual semver string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose EEZ versioning

2 participants