I did a little poetry work tonight, but I want to focus on planning for MOTR. Now, from an implementation perspective, "Shove platform-based string interpolation into a callback" is easier... except that I'm the one who has to implement everything, so I can't pass the buck on this, because it just instantly comes back to me.
So, here's what I know about how the Fragments will be used:
- Some Fragments will need to run against multiple versions of Python, and each will need to specify distinct output files.
- Some Fragments will need to run against one project per run.
- Some Fragments will need to run against all projects in one run.
From that, it seems like there needs to be an interface that takes a multi-project object, and yields some number of concrete Fragments. I don't think it makes sense to put this ability on the individual Fragments. It would probably be easier to have a general case of "doesn't need individual projects (possibly because it got a multi-project)".
One thing that just occurred to me is that, in the case of stuff like coverage erase, the platforms that it has to parameterize over are different than the platforms it has to run on. So, these should be separate at the base level, and have some kind of helper to unify them for the common case.
Another possibility is to avoid baking in the different ideas of what to parameterize against, and construct a framework for combining streams of fragments into streams of larger fragments, via zip and product. That doesn't sound right as an end-user interface, because the choice of whether to zip or product would be based on whether there was an existing parameter of the same type, which would have to be in the same order... It makes more sense to have something that can generate Fragments based on external parameters, and then those parameters can simply be looped over once.
So, because the Fragments don't directly code this, I suppose there needs to be some form of FragmentGenerator protocol... (One implementation should take a sequence of platforms, and another both a sequence of platforms and a multi-project. It might make sense to make these explicitly Python-specific.)
I'll try to figure this out later. For now, I'll be happy that I came to a decision on how to handle this. And try to wrap up.