Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move linting to ruff. #140

Merged
merged 6 commits into from
Mar 31, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 3 additions & 9 deletions .github/workflows/lint-every-pr.yml
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: chartboost/ruff-action@v1
- uses: chartboost/ruff-action@v1
with:
fetch-depth: 0
- uses: github/super-linter/slim@v4
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
DEFAULT_BRANCH: master
VALIDATE_ALL_CODEBASE: false
VALIDATE_PYTHON_BLACK: true
VALIDATE_PYTHON_FLAKE8: true
VALIDATE_PYTHON_PYLINT: true
args: "format --check"
19 changes: 5 additions & 14 deletions docs/source/devdocs.rst
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
Developer documentation
-----------------------

The project follows fairly standard developer practices. Every new feature should be associated with a test, and every PR requires linting using ``flake8`` and formatting using ``black``.
The project follows fairly standard developer practices. Every new feature should be associated with a test, and every PR requires linting and formatting using ``ruff``.

Testing
```````
Expand All @@ -11,23 +11,14 @@ If a new test requires additional data (input files, schemas, etc.), they can be

Formatting
``````````
All files should be formatted by ``black``. Lines containing text fields, including docstrings, should be between 80-88 characters in length. Imports of functions should be absolute, that is including the ``yadg.`` prefix.
All files should be formatted by ``ruff format``. Lines containing text fields, including docstrings, should be between 80-88 characters in length. Imports of functions should be absolute, that is including the ``yadg.`` prefix.


Implementing new features
``````````````````````````
**New parsers** should be implemented by:
**New extractors** should be implemented by:

- adding their schema into :class:`dgbowl_schemas.yadg.dataschema.DataSchema`
- adding their implementation in a separate Python package under :mod:`yadg.parsers`
- adding their implementation in a separate Python package under :mod:`yadg.extractors`

Each `parser` should be documented by adding a structured docstring into the ``__init__.py`` file of each new sub-module of :mod:`yadg.parsers`. This documentation should describe the application and usage of the `parser`, and refer to the Pydantic audotocs via :class:`~dgbowl_schemas.yadg.dataschema.DataSchema` to discuss the features exposed via the parameters dictionary. Generally, code implementing the parsing of specific `filetypes` should be kept separate from the main `parser` function in the module.

**New filetypes** should be implemented as sub-modules of their `parser`. They should be documented using a top-level docstring in the relevant sub-module. If the `filetype` is binary, a description of the file structure should be provided in the docstring. Every new `filetype` will have to be added into the :mod:`~dgbowl_schemas.yadg.dataschema.filetype` module as well.

**New extractors** can be registered using a shim in the :mod:`yadg.extractors` module, referring to the `filetype`. The ``__init__.py`` of each `extractor` should expose:

- an :func:`extract` function which returns an :class:`xarray.Dataset`,
- a :class:`set` named :obj:`supports`, enumerating all `filetypes` that can be extracted by the new `extractor.`

Note that a new `extractor` requires its `filetype` to be added in the :mod:`~dgbowl_schemas.yadg.dataschema.filetype` module as well.
Each extractor should be documented by adding a structured docstring at the top of the file. This documentation should describe the application and usage of the extractor, and refer to the Pydantic audotocs via :obj:`~dgbowl_schemas.yadg.dataschema` to discuss the features exposed via the parameters dictionary. If the filetype extracted is binary, a description of the file structure should be provided in the docstring. Every new filetype will have to be added into the :mod:`~dgbowl_schemas.yadg.dataschema.filetype` module as well.
2 changes: 2 additions & 0 deletions pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -60,3 +60,5 @@ yadg = "yadg:run_with_arguments"
enabled = true
dev_template = "{tag}.dev{ccount}"
dirty_template = "{tag}.dev{ccount}"

[tool.ruff]
3 changes: 0 additions & 3 deletions setup.cfg

This file was deleted.

2 changes: 1 addition & 1 deletion src/yadg/dgutils/pintutils.py
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ def _sanitize_helper(unit: str) -> str:


def sanitize_units(
units: Union[str, dict[str, str], list[str]]
units: Union[str, dict[str, str], list[str]],
) -> Union[str, dict[str, str], list[str]]:
"""
Unit sanitizer.
Expand Down
1 change: 0 additions & 1 deletion src/yadg/extractors/fhimcpt/csv.py
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,6 @@ def extract(
parameters: BaseModel,
**kwargs: dict,
) -> Dataset:

with open(fn, "r", encoding=encoding) as infile:
lines = [i.strip() for i in infile.readlines()]

Expand Down
Loading