This is going to be a quick entry.
I looked over the many, many 1.0 blockers that I put in for MOTR, and I picked one that's probably not a big deal, but it should make the code look nicer, so I started working on it. That issue is "Figure out how to lift operations on the underlying type into the context of the Input wrapper". And I think the solution is pretty simple: add the following code to the Input class:
def map(self: Input[T], function: Callable[[T], U]) -> Input[U]: return Input(function(self.path))
This can then be called like input_.map(lambda path: path / "child"), and it's a bit wordy, but it's not a big deal. In particular, it allows me to get rid of explicit references to the path field, so I can eventually change it to something that makes more sense, given that Input and Output are generic types now.
Working on this issue is one thing that will take references to the field out of the motrfile. The other is converting some of the custom actions into core actions, which is going to be a much bigger and more complicated undertaking, and maybe I should just be ready to do that one wrong the first time I try.
The central issue with bringing in the custom actions is, I have two custom actions, and I want to get rid of one, and rewrite the other, so I guess I'd rather complete and prove out the rewrite of the latter before I bring it into the core. Getting the rewrite done is going to require a bunch of other stuff. (Like the Fragment classes.)
So, low-hanging fruit in the near future, big rewrite project soon after. Sounds like a plan, and I don't care how good a plan it sounds like.