eval_results decorator replacement
#755
Commits on Sep 23, 2024
-
rf: adjust patch to import and patch
eval_resultsdirectlyPreviously the entrypoint for the patch was `_execute_command_()`. But now we aim to refactor the whole thing.
-
-
-
rf: remove needless separation of kwargs for command
Previously, kwargs for the actual command were handled semi-separately from kwargs for result handling. However, I see no benefits, only added complexity.
-
`eval_func()` and its dependencies are a spaghetti monster. This commit introduces a `ResultHandler`, a class that provides functionality to handle results produced by a command execution. This idea is to factor out all result processing from result generation code. Moreover, a caller should eventually be able to provision an alternative result handler with different implementations for filtering, and rendering results.
-
chore: import the remainder of
eval_resultsdependenciesThe aim is to jointly refactor them.
-
-
-
-
rf: establish abstract base class
ResultHandlerAnd `LegacyResultHandler` as its only implementation for now.
-
rf: separate result generation from handling of generated results
This is now done by a configurabled, dedicated handler class.
-
-
feat: dedicated getter/setter the global result handler
This replaces the initial implementation that would add yet another kwarg to each command. There is no real usecase for switching the result handler on a call-by-call basis. This new implementation follows the pattern found in libraries (like matplotlib) to set handlers or backends using top-level helper functions.
-
ci: add setup for type/code checker
This anticipates a future move to `hatch` for project and environment management.
-
fix: stop removing a
loggerattribute from the resultsThe helper `_execute_command_()` is not the place to decide on the fate of a results, or to impose any constraints on how it can be used. If a logger "does not serialize, or pollutes the output", this is only relevant, when a result needs to be serialized, or printed. Any sensible implementation of such functionality will need to have means to deal with this problem (a logger is not the only source of complications). Removing it here is therefore premature.
-
-
fix: move
eval_resultspatching to an earlier positionOtherwise it does not affect the remaining patches, like it should. One example is the `configuration` patch, which essentially replaces an entire command implementation.
-
feat: sketch of a new configuration manager
This will eventually fix datalad#397
-
feat: add legacy compatibility layer to new configuration manager
This will eventually yield a near drop-in replacement for the legacy `ConfigManager`.
-
