Coding 2021-08-09

By Max Woerner Chase

All right, now I'll stop being cagey about the task runner's name. It is MOTR, short for Max's Obvious Task Runner, though I'll probably flip-flop about whether the O should stand for "Obvious" or "Opinionated". In any case, the naming is via a slight corruption of the COINS concept, because I wanted it to be as close to "motor" as possible, and I thought "MOOTR, but pronounce it like it's a German web 2.0 startup" was too far. And I didn't have any good alternative adjectives in mind.

Now, you'd be forgiven for thinking that, because I released this, I think it has a chance of being useful to anyone in its current state, least of all myself. My goal here is to get my prototype "motrfile" to a stage where it's capable of running MOTR's own tests and diagnostics. Then, I'll cut a source release. At that point, I'll get to work addressing the various issues standing in the way of version 1.0:

Anyway, I'm starting this post early. I'll take a break for now and come back to it tonight.

All right, right off the bat it's failing, and the failure looks, I think, more or less how I want it to at this level.

MOTRError > The MOTRfile at /home/maxchase/Documents/synched/motr/motr/ encountered the following exception:
Traceback (most recent call last):
  File "/home/maxchase/.pyenv/versions/3.9.4/envs/motr-dev/lib/python3.9/site-packages/motr/controllers/", line 127, in _default
    exec(compiled_code, motr_globals)
  File "/home/maxchase/Documents/synched/motr/motr/", line 252, in <module>
  File "/home/maxchase/.pyenv/versions/3.9.4/envs/motr-dev/lib/python3.9/site-packages/motr/_api/", line 9, in build
    for requirement in requirements:
  File "/home/maxchase/Documents/synched/motr/motr/", line 133, in changes
    flake8_report_dir = api.Input(reports_dir / "flake8")
AttributeError: module 'motr.api' has no attribute 'Input'

This error is a consequence of the actual application pulling ahead of the prototype motrfile. I confess I'm not sure whether I should change the motrfile to retrieve the class from the "correct" module, or re-do the export to make Input explicitly part of the api surface.

Thinking about this, I think I want to divide the api module into different "levels". Like, ideally, you should be able to work with high-level prefab stuff (which... isn't written yet), and have the option to drop down to lower levels of abstraction to write similar but different high-level abstractions.

I don't want to rush into this, so I'm going to sleep on it for now and get back to the other "secret" project.

(Probably the right thing to do to start with is to fit the motrfile to the current interfaces, so I can tell which bits most need to change.) Anyway, that's enough planning for now.

Good night.