We have recently performed more work on the NeXus-related code in ESSsans and ESSdiffraction. Most of this is pretty generic, but due to technique-specific generic-types it is difficult to directly use a common implementation
Considerations
@jl-wynen and I discussed various options:
Provider factories in various flavors have problems with mypy, from __future__ import annotations, or both.
Cyclebane map operations would in principle work, but would result in cumbersome adapters between the mapped Nexus workflow types and the rest of the workflow (which prefers to use generic types).
More complicated approaches involving sub-pipelines (a hypothetical Sciline feature) are very unclear and likely suffer from many other problems
Conclusion
We need to keep wrappers in technique packages
Move more code into ESSreduce, keep only thin wrappers in technique packages.
Try to reuse docstrings (should mostly be generic enough) by using docstring of wrapped function.
Open questions
Would it make sense to provide common generic versions of the NeXus tools in ESSreduce, defining, e.g, RunType with some commonly used run types? This might allow for no having any wrappers for some of the technique packages.
Can we just include concrete type-vars such as RunType into a template files? Then no wrappers are needed.
Overview
We have recently performed more work on the NeXus-related code in ESSsans and ESSdiffraction. Most of this is pretty generic, but due to technique-specific generic-types it is difficult to directly use a common implementation
Considerations
@jl-wynen and I discussed various options:
mypy,from __future__ import annotations, or both.mapoperations would in principle work, but would result in cumbersome adapters between the mapped Nexus workflow types and the rest of the workflow (which prefers to use generic types).Conclusion
Open questions
RunTypewith some commonly used run types? This might allow for no having any wrappers for some of the technique packages.RunTypeinto a template files? Then no wrappers are needed.