Three Dollar Quill

All right, there's now control over syntax coloring! Probably!

While I think the task runner is close enough to tested that I'd be comfortable trying it out against actual codebases, I want to step back for now and kind of subconsciously consider a few things.

• Right now, it gathers up stdout and stderr in memory; I want to convert these to files that get streamed to a generated directory. One thing I want to ponder is having a symlink to the latest run's directory; I don't know whether that would present a significant barrier to anyone developing on Windows.
• Setting that up would also require changing the signature of the Action callable type, which isn't currently a big deal. It would be to include file objects of some kind. My current thinking is that I should go for "somewhat slower than idealized performance", and say, okay, the interface gets an asynchronous file object, then the consumer can unwrap it if a synchronous object is required. (Note that, it looks like there are various good reasons for the task runner to open these files in binary mode.)
• As a further knock-on, I think this gives me a reason to change "Actions given the same name" from a warning to an error, because if all action names are unique, it means that action logs can just use the name directly.

I'm not going to think about this specifically, but I'm also going to want, when I come back to this, to figure out the right project layout for exposing the configuration-side APIs at the project root, or possibly in some low-level submodule. I'm leaning towards the latter because the configuration side of the Python API is supposed to be a temporary thing that gets stripped out before I'm comfortable moving the version to 1.0.

Actually, let's think about the different ways this gets consumed...

• running the runner invokes an entry point, which (currently) imports the configuration file and processes it
• writing the configuration file currently involves importing various functions from inside the app
• I won't have a handle on extending the app until I try using it

Thinking about this, one thing it would be worth doing before I step away is actually writing the configuration file for the app itself, and seeing how that shakes out in practice. For example, right now the noxfile takes a minute to run, and I believe ten seconds is the realistic lower bound given the current suite, and I want to see which side it's all closer to.

I'll do that tomorrow; for now I want to clean up and get ready for bed.

Good night.