Add mypy type hints for utils

[emmuhamm]

Description

Fixes issue #852

Work in progress

WHAT DOES THIS PR CHANGE - ONE LINE.

DOCUMENT THE CHANGE BELOW OR DELETE IT

The relevant changes in the user workflow have been documented here (link URL)

Type of change

• New feature / enhancement
• Optimization
• Bug fix
• Breaking change
• Documentation

List of required branches from other repositories

WHAT PRs NEED TO BE INCLUDED TO MAKE THE CHANGE.

Change log

WHAT HAS CHANGED.

Suggested manual testing checklist

LIST COMMANDS TO DEMONSTRATE CHANGE

Developer checklist

Prior to marking this as "Ready for Review"

Tests ran on: WHAT HOSTNAME from release RELEASE_NAME

Unit tests - some tests can't be ran on the CI. This is documented. If this PR checks a feature that can't be tested with CI, this has been marked appropriately.

Integration tests - the daqsystemtest_integtest_bundle requires a lot of resources, and connections to the EHN1 infrastructure. Check the cross referenced list if you can't run these. The developer needs to run at least the .

• Unit tests (pytest --marker) passed
  • With relevant marker
  • Without marker
• Integration tests passed
  • Only daqsystemtest_integtest_bundle.sh -k minimal_system_quick_test.py
  • Full daqsystemtest_integtest_bundle.sh
• Testing skipped as there are no core code changes in this PR, this only relates to documentation/CI workflows

Final checklist prior to marking this as "Ready for Review"

• Code is clearly commented.
• New unit tests have been added, or is documented in # ISSUE NUMBER
• A suitable reviewer has been chosen from this list.

Reviewer checklist

• This branch has been rebased with develop prior to testing.
• Suggested manual tests show changes.
• CI workflows fails documented (if present)
• Integration tests passed
  • Only concern yourself if failures related to drunc are in the log files
  • If non-drunc failure appears:
    • Validate failure in fresh working area
    • Contact Pawel if unsure

Once the features are validated and both the unit and integration tests pass, the PRs is ready to be merged.

Prior to merging

Choose one of the following an complete all substeps

• Changes only affect the Run Control, are in a single repository, and do not affect the end user.
  • Changes are documented in docstrings and code comments
  • Wiki has been updated if architectural or endpoint changes
• Otherwise
  • Workflow changes demonstrated in the Change Log (if necessary)
  • Wiki has been updated (if necessary)
  • #daq-sw-librarians Slack channel notified (see below)

Once completed, the reviewer can merge the PR.

Notification message for #daq-sw-librarians Slack channel

For an single merge that changes the user workflow

The CCM WG has an isolated PR ready to merge that affects user workflows. The PR is:

_URL_

I will leave time for any comments, otherwise will merge these at the end of the work day _Insert your time zone_.

For co-ordinated merge

The CCM WG has a set of co-ordinated merges ready to merge. The PRs are:

_URL_

_URL_


I will leave time for any comments, otherwise will merge these at the end of the day.

[jamesturner246]

Hey @emmuhamm. Just saw this flash past my inbox. You can also put mypy conficg inside the pypyoject.toml, so you don't have to add another file. As in

[tool.mypy]
disable_error_code = ["import-untyped"]

I'd be more inclined to try and find and install the missing stubs from e.g. typeshed though.

[emmuhamm]

Hi James, ah yes thanks thats useful. Didn't know about typeshed so will have a go through with that.

Yeah I was wondering if it were better to have the mypy stuff in a separate file or combined the toml. After thinking about it I think ur right, keeps everything centralised

[PawelPlesniak]

Thank you for this discussion. For the linitng, I would suggest we leave that in a separate PR so that linting does not otherwise fail while we work on the mypy development. Having a configurattion in pyproject.toml would be better, but that can also be for a separate PR that closes #828

As for typeshed, I have left that as a suggestion in #828 as well. I think it would be very useful

[emmuhamm]

Note: when developing this it was discovered that ruff has two settings in drunc, one in .ruff.toml and another in the pyproject.toml.

We should probably choose which one we want to keep, and also probably propagate to mypy.

Basically

• do we want settings to be all encompassed in pyproject? or do we want each thing to have its own file?

To be discussed

[PawelPlesniak]

This is great work, thanks @emmuhamm . I left some comments. Once they are addressed I will review, but this looks like the exact changes we need towards working with mypy.

Note: when developing this it was discovered that ruff has two settings in drunc, one in .ruff.toml and another in the pyproject.toml.

We should probably choose which one we want to keep, and also probably propagate to mypy.

Basically

• do we want settings to be all encompassed in pyproject? or do we want each thing to have its own file?

To be discussed

These should be consolidated, if it can be done with the pre-commit workflows. I would expect that this can be done. The pyproject.toml contains more rigorous linting rules, I think we should go with those

[PawelPlesniak]

Thank you for this discussion. For the linitng, I would suggest we leave that in a separate PR so that linting does not otherwise fail while we work on the mypy development. Having a configurattion in pyproject.toml would be better, but that can also be for a separate PR that closes #828

As for typeshed, I have left that as a suggestion in #828 as well. I think it would be very useful

[PawelPlesniak]

Note that as per the mypy.ini comment, we will leave these until a dedicated PR for #828 gets created. In that PR, we will also need to add these to the dev settings so at commit times we can have these checks. May be worth adding something to the pre-commit config too.