Add pre-commit dependency

[jennan]

Fixes #53

• I have added a dev optional dependency group, that could be used to put other non-test related dependencies.
• In the CI/CD, I have made it install only the dev dependencies as it is not needed to install all to make it work (and also pip install .[all] will not install the current branch but the default branch develop).

[coveralls]

Pull Request Test Coverage Report for Build 13910690908

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 50.871%

---

Totals
Change from base Build 13880952241:	0.0%
Covered Lines:	6715
Relevant Lines:	12658

---

💛 - Coveralls

[jennan]

@tennlee The PR is ready. Unfortunately the CI/CD fails due to isort pre-commit doing its job I believe. So let me know if this PR should also fix this issue.

[tennlee]

I think yes, just bring isort into the mix. I did do an earlier commit bringing things into compliance at a point in time, so hopefully it won't be a large effort.

[jennan]

I think yes, just bring isort into the mix. I did do an earlier commit bringing things into compliance at a point in time, so hopefully it won't be a large effort.

I have added isort already in the pre-commit config :-).

[tennlee]

Sorry, I wasn't clear. I mean, yes, please fix the underlying issues by running isort and adding that to this PR so that we can merge the PR and also set the passing hurdle on CI/CD.

[jennan]

OK, isort broke some imports so I'll try to fix that.

[jennan]

I also suspect that, if my memory is right, some modules from PyEarthTools need to be loaded before others so that the registration mechanism kicks in... that means isort will probably have broken these too.

[tennlee]

Fixing this will also help get the codebase ready for ruff integration, which had similar issues.
If you are stuck on specific import-order issues, feel free to let me know and we might be able to introduce a fix.

[jennan]

So, it looks like there are quite a lot of circular imports, some due to subpackages importing their parent packages importing subpackages... The sorting from isort made this more visible.

For example, just looking at pyearthtools.data, I have found the following modules importing the parent module:

$ git grep "^import pyearthtools.data$" packages/data/src/
packages/data/src/pyearthtools/data/archive/extensions.py:import pyearthtools.data
packages/data/src/pyearthtools/data/archive/root.py:import pyearthtools.data
packages/data/src/pyearthtools/data/archive/zarr.py:import pyearthtools.data
packages/data/src/pyearthtools/data/catalog.py:import pyearthtools.data
packages/data/src/pyearthtools/data/download/arco/ERA5.py:import pyearthtools.data
packages/data/src/pyearthtools/data/download/cds/ERA5.py:import pyearthtools.data
packages/data/src/pyearthtools/data/download/ecmwf_opendata/opendata.py:import pyearthtools.data
packages/data/src/pyearthtools/data/indexes/cacheIndex.py:import pyearthtools.data
packages/data/src/pyearthtools/data/indexes/extensions.py:import pyearthtools.data
packages/data/src/pyearthtools/data/indexes/indexes.py:import pyearthtools.data
packages/data/src/pyearthtools/data/indexes/utilities/mixins/index_repr.py:import pyearthtools.data
packages/data/src/pyearthtools/data/load.py:import pyearthtools.data
packages/data/src/pyearthtools/data/modifications/modification.py:import pyearthtools.data
packages/data/src/pyearthtools/data/modifications/register.py:import pyearthtools.data
packages/data/src/pyearthtools/data/operations/index_operations.py:import pyearthtools.data
packages/data/src/pyearthtools/data/operations/index_routines.py:import pyearthtools.data
packages/data/src/pyearthtools/data/operations/interpolation.py:import pyearthtools.data
packages/data/src/pyearthtools/data/patterns/static.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/__init__.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/coordinates.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/default.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/interpolation.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/normalisation/default.py:import pyearthtools.data
packages/data/src/pyearthtools/data/transforms/values.py:import pyearthtools.data

I believe the right way to address these is to go through each of these children modules and ensure they don't import a parent module (e.g. using from pyearthtools.data.time import TimeDelta instead of from pyearthtools.dataimport TimeDelta).

I won't be able to do this now/today, so please @tennlee don't hesitate to have a look/push commits to this PR if you want to start fixing this without waiting for me.

[jennan]

Just an update here, I have started to go through every import issue and fixing them one by one. I have made a new branch (to be merged here eventually) to explore if this is a viable solution. See https://github.com/jennan/PyEarthTools/tree/fix_imports.
FYI @tennlee

[jennan]

I closing this PR in favor of #64. Isort related cyclic import fixes will come as separate PRs.