Three Dollar Quill

Starting again, picking up from yesterday...

• Change ASAP
  • Names
    • CommandBuilder needs a different name for the command attribute, which needs a new name for its type.
    • In fact, I believe the type should be renamed Executable, after the fact that the x bit is set on the file, and its command attribute should be name instead. The same file has some type aliases that derive from the type, and they should be updated as well. Consider renaming Metadata, mainly because it's not a very descriptive name. It might fare better if I moved it to the command_builder module. Consider that.
    • The entry module seems reasonable, but come back to it later.
    • The flex module feels like it needs an overhaul, but I'm not sure what to replace anything with. Changes may propagate to the parametric module.
    • A lot of the class names in input_accumulator are kind of awkward, but I don't have a clear idea of what to replace them with, because I think I need to figure out more about the usage. All the same, it's worth seeing if the decorators can be turned into classmethods.
    • In installers, I think maybe Environment should be ExecutionEnvironment. I'm not really sure, though.
    • Not sure if the parameters module needs anything.
    • A bunch of the functions in the parametric module could be converted to methods. I'm not sure about "should"...
    • motr._api.cli_types.registry could do with some renames. Like, the point of it is just that these are the constants, maybe, to go with the parameters.
    • The typed_mapping module and protocols could also do with a rename.
    • motr._api.cli.build could do with the same classmethod rewrite I'm considering elsewhere, if I go through with it.
    • The cli modules have the general thing of, I should probably combine the python versions adaptor and the pip arguments label into a single object of some kind. And there are other changes I want to make, that I've laid out elsewhere. I'm skimming over this stuff, so I'm going to have to go into more detail again later.
    • The python_helpers module needs the requirement_invocation function to be renamed. Not sure about anything else.
    • The reports module could have the acumulator function renamed, or not. We'll see.
    • Don't know about the pip module, name-wise. Or otherwise.
    • The package module has some functions that I should see if I can get rid of.
  • Everything else
    • isinstance() calls in the command module.
    • I'm considering dropping many uses of PVector[T], since I'm not really, like, using any part of the interface beyond what I'd get from a Tuple[T, ...].
    • isinstance() calls in the parametric_command module. Also, there are some types that could be improved with a typed mapping.
    • reduce_parameterization() could have the arguments reorganized a little so that reducer and initial_value are in a single container object.
    • Some of the internal strings in motr._api.cli.build are wrong, and need to be fixed before the next release.
• Change after the next release
  • Names
    • The cmd_ function is somewhat unfortunate. Consider converting to a classmethod?
    • I'm a little iffy on whether to keep the Input and Output names. They could be Prerequisite and Outcome, for example, but those are mega long. This would spill over into the not_output module.
    • mkdir and make_parent could be moved if cmd_ is, for consistency.
    • Same for write_bytes.
    • I think there could be a better name for motr._api.build and its build() function, but I think to find it, I'd also need to find a better name for motr.core.registry. Which, to be fair, it definitely needs a better name.
    • I've got a note to rename motr._api.requirements.action to task. This would go along with some changes to core.
    • Similarly, name_target to name_outcome.
    • About requirements overall... I feel like something should change, but I've got time to figure things out.
    • And, target to outcome.
    • I've got a rename queued up for motr.core.target_name as well.
    • And motr.core.target.
  • Everything else
    • The motr._api.actions modules, as well as motr._api.cli.build need an overhaul to their interfaces, which is going to start with changes in motr.core.runner. Basically, I want to change from "return a mapping of output when done" to "pass in some kind of callback for registering output streams".
    • I want to beef up the details of some of the typed_mapping stuff, and also I want to spin it out into its own package. Making it into a package would allow me to use it in other projects, and also make the test runs faster in MOTR.
    • I'm not sure if this counts as "name" or "everything else", but I'm not totally sold on the way I'm doing re-exports from the api module. Like, is this confusing to people who aren't me? I need to figure that out.
    • The base controller is huge and needs to be broken up. I don't know how, exactly, but it's too big.
    • I should see whether I want to add any classes to the exc module.
    • I've got a bunch of renames cued up in motr.core.registry. The thing I'd like to figure out is, what's a better name for all of this than "registry"? DependencyGraph? Let's go with that for now.
    • As I said, I want to tweak some things in motr.core.runner. Like, renaming RuntimeAction to Task, and Target and Action to, um... Apparently, Request, and, let's say... RequestTask.
    • motr.ext.ext_maybe_format I think needs to be broken up into multiple extensions, but we'll see.
    • Paired changes to motr.main and motr.motr_app around disabling Cement's ctrl-c signal handling so Trio can have it.
    • The line CONFIG["motr"]["foo"] = "bar" needs to go.

Well, that's a good start for noting this stuff down. I did this earlier in the day, so maybe I'll feel like making some of these changes later. We'll see.

Okay, it's later, and I did some updates. Things are better, but there's more to be done.

Good night.