Three Dollar Quill

I worked on a few things today. A little bit of Fiasco writing. I tried getting the first scene done. I'm not sure if it's any good. I think I'm really feeling the fact that I have the energy of only one person here.

Anyway, I did some random cleanup on MOTR, and tried to revamp the color schemes on all of the reports. I'm not sure how well I did, because the flake8-html styling is both elaborate and a little weird. We'll see what I think when I start working seriously on this again.

To get ready for that, let's consider the basic kinds of interface I want to build for these modules:

• Constructing invocations that don't need a module. For these, it should work to define a function that takes Parts, and may allow passing a different command. For handling "different commands", my gut reaction is to put the command in a "reified partial", so there's an update method and a normal call.
• Constructing invocations that need a module. These need to pass data into the module constructor.
• Module constructors. These should just need a string argument to handle data paths and target names.

I think the cohesive approach to this is a builder object. And if we can use the Invocation itself... The main obstacle there is that it doesn't quite fit with the structure of the Invocation object, but I think that might be a problem with the Invocation object.

I'm confusing myself trying to work this out in my head, so I'm going to try to step back for a moment. For dealing with these modules, I want to accumulate metadata that will properly identify the paths relevant to the specific Invocation. And this was supposed to be a solved problem. It's the path_segments field on the Pip object. So, to work with this, I need to make sure that the outer command has access to the inner command's label.

Side note, I just noticed that the way I'm setting up the pytest wrapper looks wrong. It needs a Command class that makes the Input an extra and just resolves to a string.

Now, back to the issue of handling Labels and moving them between different wrappers... I hope I'm missing something, because this is making my head hurt. The nature of the Labels being used has to be specific to the operation being performed.

I should explain a little about the Labels. I'm using them for various purposes at this high level, but the purpose in this context is to track information about the different virtual environments in play. I'm trying to plan for having multiple virtual environments in play because I think that's required to type check Python 2 code with mypy. But then, we have a situation where an Invocation can have 2 Labels associated with it.

Okay, here's a thought. Stop thinking about the Labels, because I just remembered that the parametric aspect of this is handled by the Objects and Items objects, as well as the Flex objects. If the design of all of this sounds like a horrible rats' nest, that's

probably accurate.

Except I'm not sure if anything is handling the specific case I'm thinking of... The parameter-ish thing I want to inject is "what is running this module". I really hope I took care of this somehow. So, what would "taking care of this" look like?

The current motrfile hardcodes a lot in this area, and I'm starting to think I just genuinely overlooked the issue here. For now, let's assume I did, and try to lay out a solution.

Well, the motrfile requires a path to be passed to the run_pytest helper. How far can I get by taking a similar approach? The direct translation of this would be having a Callable[[str], Invocation, but the motrfile calls it directly. This works, but I feel like there should be a more elegant solution. I think part of such a solution would look something like:

• Track some kind of "output context" on Invocations.
• Provide facilities at a lower level to pull this context into the output generation.
• Possibly rewrite the Flex interface to route it through there?

If I'm routing this data through the Flexes, then the obvious question is if there's some way for the FlexOutput to inject it into other parts of itself.

I've been going in circles, and I'm tiring myself out. I'm starting to think that my only hope of getting this all to make sense is a comprehensive review of the architecture. And I'm not up for that right now, so for the moment, I am done.

Good night.