Adding stubs, and their inclusion in the venv

[PawelPlesniak]

Description

Prepares the repository for static type checking with mypy. The py.typed file is required to indicate that the code is ready for type checking, as per the PEP561 standards.

Type of change

• Documentation (non-breaking change that adds or improves the documentation)
• New feature or enhancement (non-breaking change which adds functionality)
• Optimization (non-breaking change that improves code/performance)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (whatever its nature)

Testing checklist

• Unit tests pass (e.g. dbt-build --unittest)
• Minimal system quicktest passes (pytest -s minimal_system_quick_test.py)
• Full set of integration tests pass (dunedaq_integtest_bundle.sh)
• Python tests pass if applicable (e.g. python -m pytest)
• Pre-commit hooks run successfully if applicable (e.g. pre-commit run --all-files)

Comments here on the testing

Further checks

• Code is commented where needed, particularly in hard-to-understand areas
• Code style is correct (dbt-build --lint, and/or see https://dune-daq-sw.readthedocs.io/en/latest/packages/styleguide/)
• If applicable, new tests have been added or an issue has been opened to tackle that in the future.
  (Indicate issue here: # (issue))

[PawelPlesniak]

Note, dbt-build --lint, has uncovered several issues that have not been addressed, as these are not associated with changes made to this repository. The logs are not included here ars they are very long.

[jcfreeman2]

I would propose we allow the installation of *.pyi files be handled automatically by the daq_add_python_bindings function, as is done in DUNE-DAQ/daq-cmake#172, rather than adding logic to CMakeLists.txt for this.

[PawelPlesniak]

That is a good suggestion, thanks @jcfreeman2
I have implemented this, the remainder should be good to go in after DUNE-DAQ/daq-cmake#172 goes in

[PawelPlesniak]

Regarding commit e20ab57, here are the notes
When running the following command from a work area's sourcecode path, using either a commit from prior to this one, or using develop

pybind11-stubgen conffwk

Errors are reported as

pybind11_stubgen - [  ERROR] In conffwk._daq_conffwk_py._Configuration.create_obj : Invalid expression 'dunedaq::conffwk::ConfigObject'
pybind11_stubgen - [  ERROR] In conffwk._daq_conffwk_py._Configuration.destroy_obj : Invalid expression 'dunedaq::conffwk::ConfigObject'
pybind11_stubgen - [  ERROR] In conffwk._daq_conffwk_py._Configuration.get_obj : Invalid expression 'dunedaq::conffwk::ConfigObject'
pybind11_stubgen - [  ERROR] In conffwk._daq_conffwk_py._Configuration.get_objs : Invalid expression 'dunedaq::conffwk::ConfigObject'
pybind11_stubgen - [WARNING] Raw C++ types/values were found in signatures extracted from docstrings.
Please check the corresponding sections of pybind11 documentation to avoid common mistakes in binding code:
 - https://pybind11.readthedocs.io/en/latest/advanced/misc.html#avoiding-cpp-types-in-docstrings
 - https://pybind11.readthedocs.io/en/latest/advanced/functions.html#default-arguments-revisited

When first registering the conffwkobject, these errors are resolved.

[jcfreeman2]

This all passes the eye test. Additionally:

• This builds as part of a test build (MYPYFD_DEV_260723_A9) which uses the newest version of daq-cmake cut this morning, and all integration tests pass - i.e., "does no harm"
• If you locally build it in a work area, *.pyi files are installed
• They're not in the test build, but that's the fault of daq-cmake (see new Issue DUNE-DAQ/daq-cmake#174 for more)