Move types to subpackages - #607

Would there be any use in providing a default set of monitors? (Monitor1-4?)

I don't think so. We shouldn't use them in workflows because they carry no meaning. So I think they would only be good for testing, and then we can easily define them in the tests.

Why is the SampleRun special?
Shouldn't we remove all in the future, and sub-packages can decide if they want to name it SampleRun or something else?

Is there any code internally to essreduce that makes use of SampleRun or is it only in the tests/docs?

It is special in how I and maybe we think about workflows. But that is not a good argument on its own.

There are some uses in live and polarization. Removing the ones in live might be tricky. But maybe that code should be in esslivedata anyway? And for polarization, there is this: #615

I would have thought that everything in essreduce could just be RunType, unless I am forgetting something?

But maybe that code should be in esslivedata anyway?

Yes, I would vote to move it there.

@SimonHeybrock ?

I think every instrument does sample-runs, so having a unified name makes sense (or else every instrument will have their own naming convention)?

In ESSlivedata I actually just used this as a default in some cases. Defining AnyRun would be more thruthful. But there are probably also uses via technique packages.

or else every instrument will have their own naming convention

They seem to already do that with BackgroundRun, OpenBeamRun, EmptyRun, DirectRun... so maybe leaving the freedom to define a sample run is not so different?

So was the conclusion here to keep SampleRun and move forwards with the changes as they are?

I think so.