Review complete; most comments on the PRs.
One more big-picture comment that doesn't appear there: I feel like the SourceSelector design overall conflates pluggability of particular algorithms for filtering with predefined combinations of filters that are useful for particular purposes; there are concrete SourceSelectors that fit into both categories. I think it's a natural response to the way our configuration system and table library work, and doing better could be quite difficult (see below), but the result of this is that if you have a SourceSelector that applies N-1 cuts you care about, and another one that applies the Nth one, the only way to combine them is to write a new SourceSelector. That has already lead to a proliferation of very similar SourceSelectors, and hence a lot of boilerplate.
My ideal design for this would have a single nonpolymorphic SourceSelector Task with:
- a registry of pluggable polymorphic predicate objects that each can compute a single non-trivial boolean for each source;
- a DSL for combining those predicates with trivial less--than/greater-than/equals (etc) tests on fields using boolean logic; expressions in that DSL would be part of the configuration of the SourceSelectorTask;
- a mechanism for assigning particular expressions (e.g. "what we use for PSF star selection") to particular flag fields, allowing them to be used both as outputs for later diagnostic use and as inputs to other expressions.
That's obviously extremely ambitious, and I haven't thought through how we'd want to go about accomplishing it (or even whether it'd be worthwhile to try). I'm mentioning it here largely so others can be on the lookout for low-hanging fruit that moves in something like that direction when we run into the limitations of the current design in the future.