Three Dollar Quill

The first thing on that list I put together yesterday was fixing # TODO: comments. Instead of jumping in at random, I'm going to try to prioritize them. Some are good to work on now, and others should go on the "release" topic once I've fixed up the coverage.

Soon:

• Reconsider the name of "requirements", at both a type and module level.

• Reconsider the name of "registry", at both a type and module level.

• Rename (Input|Output).path to value.

• Reconsider the names of Input and Output.

• I was thinking of renaming Target and related classes to Outcome, but maybe what I want to do is call them Artifact, or something? I feel like any choice I make is going to have some terminological issues. Like, Target isn't inaccurate, but doesn't communicate much. Contrastingly, Artifact gives a clearer picture of the general usage, but doesn't really fit some critical cases. Looking at both of those choices, Outcome actually just feels like a bad compromise... Basically, this name should refer to something that can be thought of in three related contexts:

  • An effect of a task that can be reasoned about in other contexts, an Outcome.
  • A condition that must hold in order for a task to start, a Prerequisite.
  • An externally visible result that the user can request MOTR to provide, currently a NamedOutcome.

Later:

• Clean up the pip installer code
• Reconsider the name of the base_cmd helper function.
• I've got a TODO in the parametric module that I don't remember the context for what I was saying... Basically, one of the validation helpers on the parametric metadata is meant to determine whether the metadata can be used in an InputAccumulator. The case in question triggers when the multivalue_labels field has a non-None value. When that field has a non-None value, that means it contains a collection of labels. No labels except for the ones in that collection are allowed to take more than one. That means it's acceptable for the InputAccumulator to accumulate more labels, as long as ultimately, only the multivalue_labels take on multiple values. I think that means I can just remove the branch that emits the message? Maybe?
• Speaking of InputAccumulator... Oh yeah, I added a bunch of classes and protocols, and now I don't know if my terminology makes any sense. But anyway, the only TODO comment I have in there is, I think, about how I'm calling a validation helper where the name of the helper doesn't match the context it's called in, which implies that I need to reconsider the name of the not_flex_out_because() helper, or write an explanatory comment justifying its usage.
• There's a pretty basic and more-or-less self-explanatory TODO in parametric_command that's waiting for proper test coverage.
• Bonus thought: cli_types doesn't seem like a good name?

I can make some of the "soon" changes easily enough, but others I feel like I need to take more time to consider them.

...

Update from the end of the night: I did the path to value renames because they were trivial, but I need to give some more thought to the others.

Good night.