Refactor validators - Githubissues

sfmig commented 3 weeks ago

Description

Suggestion to split validators into two modules.

What is this PR

[ ] Bug fix
[ ] Addition of a new feature
[x] Other

Why is this PR needed? We are thinking of ways to make it easier for contributors to add support to new files. Since this is a part of the codebase that may be visited often by external contributors, it may be nice to make it accessible and readable.

What does this PR do? Splits the validators into two modules:

movement.io.validators.datasets: holds the classes for validating data intended for a movement dataset.
- For now, it has only a ValidPosesDataset, but we are planning to add a ValidBboxesDataset soon (see #201).
movement.io.validators.files: holds the classes for validating files.

References

\

How has this PR been tested?

Tests pass locally and on CI.

Is this a breaking change?

No.

Does this PR require an update to the documentation?

I modified the API reference to show validators for files and datasets separately, but open to suggestions if something else is preferred.

Checklist:

[x] The code has been tested locally
[ n/a ] Tests have been added to cover all new functionality
[x] The documentation has been updated to reflect any changes
[x] The code has been formatted with pre-commit

codecov[bot] commented 3 weeks ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.68%. Comparing base (cf0a6b1) to head (3217584).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #204 +/- ## ======================================= Coverage 99.68% 99.68% ======================================= Files 11 12 +1 Lines 639 643 +4 ======================================= + Hits 637 641 +4 Misses 2 2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

niksirbi commented 3 weeks ago

Now that I've thought more about it, I think movement.validators.files and movement.validators.datasets makes more sense. We are likely to also use validators in non I/O context, e.g. before performing a computation that assumes a valid dataset of one sort or another.