Modernize library and coding conventions

[Zeitsperre]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes issue #xyz
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• HISTORY.rst has been updated (with summary of main changes)
• I have added my relevant user information to AUTHORS.md

• What kind of change does this PR introduce?:

• Migrates from setup.py to pyproject.toml
• Synchronizes dependencies between pip and conda configurations
• Implements the ruff formatter (replacing flake8)
• Adds several docstrings to modules, classes, methods, and functions
• Raised clisops version to 0.14.0 to make use of pooch.

• Does this PR introduce a breaking change?:

Yes, very much so. The testing and configuration code will be adapted to the new testdata system. Unnecessary dependencies should be removed.

• Other information:

[Zeitsperre]

@cehbrecht

Is it possible that roocs-utils has some logic in place to parse project names from hard-coded filepaths? I can't seem to be able to get any test_operations tests to resolve, despite ensuring that the roocs.ini generated by daops is consistent with the new cache location, ie:

    [project:cmip5]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip5/data/cmip5

    [project:cmip6]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip6/data/CMIP6

    [project:cordex]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cordex/data/cordex

    [project:c3s-cmip5]
    base_dir = /home/me/.cache/mini-esgf-data/v1/gws/nopw/j04/cp4cds1_vol1/data/c3s-cmip5

    [project:c3s-cmip6]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip6/data/CMIP6

    [project:c3s-cordex]
    base_dir = /home/me/.cache/mini-esgf-data/v1/gws/nopw/j04/cp4cds1_vol1/data/c3s-cordex

I'm wondering if roocs-utils is building its own .ini file? The issue appears to be the project name not identifable by roocs_utils.project_utils.DatasetMapper.

[cehbrecht]

@cehbrecht

Is it possible that roocs-utils has some logic in place to parse project names from hard-coded filepaths? I can't seem to be able to get any test_operations tests to resolve, despite ensuring that the roocs.ini generated by daops is consistent with the new cache location, ie:

    [project:cmip5]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip5/data/cmip5

    [project:cmip6]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip6/data/CMIP6

    [project:cordex]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cordex/data/cordex

    [project:c3s-cmip5]
    base_dir = /home/me/.cache/mini-esgf-data/v1/gws/nopw/j04/cp4cds1_vol1/data/c3s-cmip5

    [project:c3s-cmip6]
    base_dir = /home/me/.cache/mini-esgf-data/v1/badc/cmip6/data/CMIP6

    [project:c3s-cordex]
    base_dir = /home/me/.cache/mini-esgf-data/v1/gws/nopw/j04/cp4cds1_vol1/data/c3s-cordex

I'm wondering if roocs-utils is building its own .ini file? The issue appears to be the project name not identifable by roocs_utils.project_utils.DatasetMapper.

@Zeitsperre not sure if I understand.

Guessing the project in the roocs.ini is a tricky and confusing thing. There are the [project:abc] sections which are used to guess it from the file path. And it can also look into the dataset and use the mapping field to figure out the attribute with the project name:

• https://github.com/roocs/roocs-utils/blob/master/tests/test_project_utils.py
• https://github.com/roocs/roocs-utils/blob/9703631c6e5d46fb09c26c9b9f60e4c83d34a929/roocs_utils/etc/roocs.ini#L27

roocs_utils provides the default values for roocs.ini and these get overwritten in daops and rook ... or by the site deployment config.