[pre-commit.ci] pre-commit autoupdate (#1188)

* [pre-commit.ci] pre-commit autoupdate

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.4.0 → v4.5.0](pre-commit/pre-commit-hooks@v4.4.0...v4.5.0)
- [github.com/codespell-project/codespell: v2.2.5 → v2.2.6](codespell-project/codespell@v2.2.5...v2.2.6)

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

.pre-commit-config.yaml

@@ -7,7 +7,7 @@ exclude: |
   )
 repos:
   - repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.4.0
+    rev: v4.5.0
     hooks:
       - id: trailing-whitespace
       - id: end-of-file-fixer
@@ -34,7 +34,7 @@ repos:
       - id: flake8
 
   - repo: https://github.com/codespell-project/codespell
-    rev: v2.2.5
+    rev: v2.2.6
     hooks:
       - id: codespell
         # Checks spelling in `docs/source` and `echopype` dirs ONLY

docs/source/contributing.rst

@@ -37,7 +37,7 @@ This diagram depicts the complete workflow we use in the source GitHub repositor
 - ``doc patch``: Updates to the documentation that refer to the current ``echopype``
   release can be pushed out immediately to the
   `echopype documentation site <https://echopype.readthedocs.io>`_
-  by contibuting patches (PRs) to the ``stable`` branch. See `Documentation development`_
+  by contributing patches (PRs) to the ``stable`` branch. See `Documentation development`_
   below for more details.
 - ``code patch``: Code development is carried out as patches (PRs) to the ``dev``
   branch; changes in the documentation corresponding to changes in the code can be
@@ -224,7 +224,7 @@ To view the HTML files generated by Jupyter Book, open the
 ``docs/_build/html/index.html`` in your browser.
 
 Jupyter Book `configurations <https://jupyterbook.org/en/stable/customize/config.html>`_ can be found in the ``docs/source/_config.yml`` file.
-The `table of contents <https://jupyterbook.org/en/stable/structure/toc.html>`_ arragements for the sidebar can be found in ``docs/source/_toc.yml`` file.
+The `table of contents <https://jupyterbook.org/en/stable/structure/toc.html>`_ arrangements for the sidebar can be found in ``docs/source/_toc.yml`` file.
 
 When ready to commit your changes, please pull request your changes to the `stable` branch. Once the PR is submitted, the `pre-commit` CI will run for basic spelling and formatting check (See the `pre-commit hooks section <contributing.html#pre-commit-hooks>`_ for more details). Any changes from the `pre-commit` check have to be pulled to your branch (via `git pull`) before your push further commits. You will also be able to view the newly built doc in the PR via the "docs/readthedocs.org:echopype" entry shown below.
 

docs/source/data-proc.md

@@ -1,6 +1,6 @@
 # Data processing
 
-Echopype data processing funcionalities are structured into different subpackages with expandability and a series of [data processing levels](processing-levels) in mind. Once the data is converted from the raw instrument data files to standardized [`EchoData` objects](data-format:echodata-object) (or stored in `.zarr` or `.nc` format) and calibrated, the core input and output of most subsequent functions are generic [xarray `Datasets`](https://docs.xarray.dev/en/stable/generated/xarray.Dataset.html). This design allows new processing functions be easily added without needing to understand specialized objects, other than functions needing access of data stored only in the raw-converted `EchoData` objects.
+Echopype data processing functionalities are structured into different subpackages with expandability and a series of [data processing levels](processing-levels) in mind. Once the data is converted from the raw instrument data files to standardized [`EchoData` objects](data-format:echodata-object) (or stored in `.zarr` or `.nc` format) and calibrated, the core input and output of most subsequent functions are generic [xarray `Datasets`](https://docs.xarray.dev/en/stable/generated/xarray.Dataset.html). This design allows new processing functions be easily added without needing to understand specialized objects, other than functions needing access of data stored only in the raw-converted `EchoData` objects.
 
 The section [**Data processing functionalities**](data-proc:functions) provides information for current processing functions and their usage.
 
@@ -9,6 +9,6 @@ The section [**Additional information for processed data**](data-proc:additional
 (data-proc:format)=
 ## Format of processed data
 
-Once raw data (represented by the `EchoData` objects) are calibrated  (via [`compute_Sv`](echopype.calibrate.compute_Sv)), the calibrated data and the outputs of all subsequent [processing functions](data-process:funcionalities) are generic [xarray Datasets](https://docs.xarray.dev/en/stable/user-guide/data-structures.html#dataset).
+Once raw data (represented by the `EchoData` objects) are calibrated  (via [`compute_Sv`](echopype.calibrate.compute_Sv)), the calibrated data and the outputs of all subsequent [processing functions](data-process:functionalities) are generic [xarray Datasets](https://docs.xarray.dev/en/stable/user-guide/data-structures.html#dataset).
 We currently do not follow any specific conventions for processed data, but we retain provenance information in the dataset, including the [data processing levels](./processing-levels.md).
 However, whether and how data variables used in the processing will be stored remain to be determined.

echopype/echodata/sensor_ep_version_mapping/v05x_to_v06x.py

@@ -753,7 +753,7 @@ def _rename_and_add_time_vars_ek60(ed_obj):
     the variable time3, renames the variable ``water_level``
     time coordinate to time3, and changes ``ping_time`` to
     ``time2`` for the variables ``pitch/roll/vertical_offset``.
-    2. For EK60's ``Envrionment`` group this function renames
+    2. For EK60's ``Environment`` group this function renames
     ``ping_time`` to ``time1``.
 
     Parameters

echopype/tests/calibrate/test_cal_params.py

@@ -148,7 +148,7 @@ def test_param2da(p_val, channel, da_output):
             marks=pytest.mark.xfail(strict=True, reason="input sa_correction does not contain a 'channel' coordinate"),
         ),
         # input individual param:
-        #   - with channel cooridinate but not identical to argin channel: fail with value error
+        #   - with channel coordinate but not identical to argin channel: fail with value error
         pytest.param(
             "EK80",
             {"sa_correction": xr.DataArray([1, 1], dims=["channel"], coords={"channel": ["chA", "B"]})},
@@ -157,7 +157,7 @@ def test_param2da(p_val, channel, da_output):
                 reason="input sa_correction contains a 'channel' coordinate but it is not identical with input channel"),
         ),
         # input individual param:
-        #   - with channel cooridinate identical to argin channel: should pass
+        #   - with channel coordinate identical to argin channel: should pass
         pytest.param(
             "EK80",
             {"sa_correction": xr.DataArray([1, 1], dims=["channel"], coords={"channel": ["chA", "chB"]})},