Skip to content

introduce a common base class for components in AnalysisBase

Nils Erik Krumnack requested to merge krumnack/athena:asg_component into 21.2

So, I started developing a dual-use service base class, so that we could migrate from public tools to services where needed. This is particularly relevant as we move to release 22 where public tools are discouraged and services are the designated replacement. However, building this I found myself replicating a lot of the configuration capabilities in AsgTool and AnaAlgorithm, something which would have to be repeated for dual-use re-entrant algorithm and any other dual-use component we may introduce in the future. So instead I created a common base class for all component types inside AnalysisBase, which reduces the complexity of implementing the component-specific base classes.

For now this is mostly moving code present created for AsgTool and AnaAlgorithm into newly created common base classes. There is some amount of cleanup that could be done in the future. We could also discuss/decide what sort of functionality we want in that common component base classes, or what we don't want, e.g. AsgTool allows users to change the name of the tool after initialization which doesn't seem like something we would want to allow. However, I do not want to do that discussion/cleanup as part of this merge request.

We could also discuss whether we want to introduce an AsgToolConfig class to allow for a simpler/more robust way of creating tools stand-alone, as an alternative and/or backend to AnaToolHandle. This could be dual-use, or only for AnalysisBase. Ideally that would even enable us to drop AnaToolHandle in master, as AnaToolHandle has unfortunately turned into a rather complex, fragile and confusing construct, and it isn't as needed anymore given that we now have dual-use python configurables.

I hope people agree with the general design, otherwise we probably can/should discuss this at the next AMG meeting.

cc @alister @lheinric @akraszna

Merge request reports