Three Dollar Quill

I'm feeling a little rough right now, and I think focusing on MOTR might help, so, early coding post, let's go.

All right, there are two major aspects of the current motrfile that I still have to document. Here's the mypy command:

mypy --html-report [input-dir] --junit-xml [output-xml] [src-param], where the input-dir has an associated HTML output. There are three Options here, and a base Fragment with an allowed_codes of {1}. The Options break down into "specifying output files" and "specifying an input directory, and it all basically makes sense.

The pyinstrument command goes like this:

pyinstrument --renderer html --outfile [output-html] -m [module]. I'd say --renderer html --outfile [output-html] should be all one Option from the user's perspective. I don't remember whether pyinstrument forwards the return codes from the module, but I know pyspy doesn't, and I sort of remember that being a point of difference between them, so maybe it does? This is really easy to check, but I don't feeeeeel like it...

That's the details of usage. A few random thoughts:

• The extra_io field is the easiest to overload, because extra Inputs and Outputs just coexist next to each other.
• I think the most sensible way to handle overloading args is to, like I said, have some specifiable prefix (and maybe suffix), and just put the whole thing together before concatenating all the different overlapping versions.
• I'm not sure what would make the most sense when it comes to environment variables. I see "require a different name" and "pack the arguments together in some way" as possibilities, but I'm not sure what I really want. I can just disallow it until I have a use case.

Thinking more about how I want to reuse components (like, ideally, I should be able to construct the pytest module invocation builder once, which means the output xml path needs to have a component that varies per-registry in terms of invocation). It looks like, given that consideration, I lucked into the correct answer to one of the design questions I was considering earlier.

The question in that case is, when does this per-call variation get introduced? I think what I'd like to see is some data that somehow gets injected and recombined at the Builder level, because doing it at the Fragment/Option level seems like it's too late.

I could imagine doing some combinatoric stuff will multiple choices, but all I need currently is one per full Fragment[Script, ...]. I'm inclined to say it should be a tuple of strings for now.

... and thinking about this, I realized that I'm sometimes going to want to ensure the directory is created, which means that the ultimate construction needs to be a Requirements, and there needs to be a way to generate Mkdir and probably WriteBytes RuntimeActions to accompany an Option with an Input...

Well, now I should be prototyping the interface from the motrfile side, because this seems like a big, complicated, something.

Okay, time to wrap up, because that's enough of that for now.

Good night.