Coding 2023-01-28

Tags:
By Max Woerner Chase

All right, I'm not touching the code for MOTR, but I want to plan things out for later.

Here are the modules that should guide my changes later:

The goal is to eliminate the map_over_selection module. I've got a two-ish part plan to do this. First, as I've said, I want to rework the artifact module to stop using the *Accumulator classes, by reorganizing the Output class. The other part is to replace the MapOverSelection class. The MapOverSelection basically associates a Label with a function that maps that label's associated value to a PathStr.

The thing I realized is that this is basically equivalent to a Parametric[PathStr] with a bunch of restrictions on its metadata. My goal is to eliminate the usages of this class by figuring out the actual metadata restrictions, and having the code require those restrictions, where applicable. This will actually make the code more reliable than it is now, because some of those restrictions are currently enforced, at best, by convention, which makes this code even more useless than one might reasonably expect for anyone who isn't me.

Here's some background:

There's sort of a latent mental model I have, of a division of the files that MOTR works with, into two categories: source, and artifacts. Source files are the background or basis for the operations that MOTR carries out, and are expected to be tracked in a source control system like Mercurial, Pijul, Darcs, Fossil, Bazaar, Perforce, Subversion, etc. Artifacts are anything that MOTR creates based on its configuration and the source files. This includes generated constraint files, static analysis, test results, coverage reports, profile data, and, like, anything else that could make sense there.

The parametric_command module divides the paths that are fed into command constructors into three categories:

The first two groups are in better shape than the third. The way the third group is represented is a bit wonky, so I'm just going to describe what I think it should be doing:

There is a Parametric[T_co] and one or more Parametric[PathStr]s. All Parametrics that are any more than mildly complicated have metadata relating to selection labels. These two groups of Parametrics must have metadata requirements that are, um, complementary? Basically, the latter group feeds into the pipeline that creates artifacts, so whenever there's a different value from the Parametric[T_co], the Parametric[PathStr]s should collectively have a different value.

This system kind of breaks down if the functions that make up a Parametric end up mapping two possible Selection values to the same output, and my advice is to simply, not do that. This, kind of sucks, but I have no idea how to express "this function must be injective" as a Mypy-compatible annotation. To be fair, I don't think this is a particularly unique shortcoming of Python.

Anyway, it's getting late, and I'm getting tired.

Good night.