Three Dollar Quill

All right, let's start another pass through the MOTR code, to see what changes I want to make. I'm going to divide this into two pairs of categories: changes to make as soon as possible versus after the next release; and changes to names, and everything else. My plan is to hold off on "everything else" until I have full test coverage, rather than 94%.

But let's break this down:

• 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"...
  • Everything else
    • isinstance() calls in the command module.
    • 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.
• Post-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.
  • Everything else
    • I didn't get to this normally, but the line CONFIG["motr"]["foo"] = "bar" needs to go, for obvious reasons.

I got distracted with stuff today, so I didn't have time to get through all of this. Tomorrow, I'll pick back up from the parametric module.

It's nearly midnight.

Good night.