I'm still putting together editing plans based on the feedback I got. I hope I get to the point where I'm done planning stuff out for a bit. Then, take a break for at least a few days. Then start doing the rewrites. This is supposed to be fun, so I don't want to force myself into the meat of it.
Anyway, moving on from that for now, I took a look at MOTR's codebase, and it should be no problem to change the report path code. It means removing a usage of a helper function, but if the helper function isn't being helpful then... don't use it. Here's about what needs to happen:
- Factor the recursive code in ParametricCommand into independent methods
- Add a field for representing "segments" of the reports path
- Add that field to the relevant ParametricCommand instances, or into the helpers
- Write a recursive method to combine the field
- (It may be possible to write some kind of decorator to abstract out the recursion but that is not a priority right now)
- Inject the field into a label that is re-exported by the reports helper module
- Rewrite the reports helper to retrieve the injected label, combine it with an optional argument, and use that as the base parametric for an InputAccumulator
That's some of the tricky stuff worked out.
Other things that occurred to me as I looked into this:
- It should be possible to wrap stuff relating to junit into a helper function
- ... which has to be applied to a Parametric, so after ParametricCommand.build() is called
- Because the version information propagates "outward" from modules, it should work to convert the module field into a union that either has a module or an adaptor; doing this removes a line of boilerplate from various parts of the API, and might simplify things even more than that suggests
- It may be possible to put all of this into a callable object, such that it's reasonable for a motrfile to have no explicit control flow. (Users could then choose to add control flow that keys off of environment variables or something. I'm not going to bother trying to stop these hypothetical users.)
All in all, exciting times ahead for MOTR, which is good, since I'd like to feel comfortable focusing on any other python project at some point. Anyway, it's late, and I should wrap up.