Allow selecting raw/proc data in components layer

[takluyver]

Preparing for the future when raw & proc data has different names.

You can pass raw=True, False or None. The default is None, which tries to preserve the legacy behaviour of using proc if possible and raw if not.

Opening a draft PR to try the CI.

[TimBerberich]

I went over the code changes in extra_data/components.py, though I still have to run the tests.
Seems good to me, here are some minor questions:

• Why was the regex capture group 'detname' (line 123) removed. To me it seemed clearer to call

     detector_names.add(m.group('detname'))

  than (line 234 in current version )

    detector_names.add(m.group(1))

  one could even omit the .group and simply call

     detector_names.add(m['detname'])

  is there a reason to use .group.
• In the funciton def _find_detector_names(cls, data): (line 226), why do we use the regular expressions for raw and proc data sources instead of only using the capture group for detector names

  re_detname  = re.compile(f'({cls._det_name_pat})')

  by the name of the function it should not care about raw or proc just the detector names that are found.

[TimBerberich]

Tests all passed. And the major added test test_modern_corr_sources looks good to me.

[takluyver]

Why was the regex capture group 'detname' (line 123) removed.

Good question, I don't know why I did that. I'll put it back.

In the funciton def _find_detector_names(cls, data): (line 226), why do we use the regular expressions for raw and proc data sources instead of only using the capture group for detector names

In this code we only care about the detector data sources - there might be other sources related to detector control, power supply, data processing etc. in the run, which might introduce extra detector names. We don't want to throw an error saying you have to pick from these 3 names if 2 of them won't work.

[philsmt]

Thanks, LGTM! This looks really neat.

[philsmt]

Nitpick, but why no ValueError?

[takluyver]

Good catch. I sometimes write Exception as a placeholder when I haven't figured out what the right type is.

In this scenario, what do you think about using SourceNameError? If we had had distinct source names from the beginning I think this would be a clear choice, but it could be somewhat confusing if the relevant source names are there, just pointing to the wrong thing.

[takluyver]

Following discussion, I used SourceNameError when you want corrected data and only raw is there, because it can point to the new corrected source name, which will definitely be absent.

But when you want raw data and the .../DET/... source names point to corrected data, it seems confusing to say those sources are missing, so in that case I raise ValueError. Hopefully the disparity won't matter too much - the error message is probably the important thing in either case.

[takluyver]

prnote:
Detector data classes have a new raw= parameter. In newer runs, both corrected and raw detector data can be accessed (depending on how you use open_run). Pass raw=False or True to specify which kind of data you want. The default behaviour is to use corrected data if available, and raw data if not, for compatibility with existing code. Older runs use the same source names for raw & corrected data, so only one kind will be accessible.