Coding 2023-04-01

Tags:
By Max Woerner Chase

I went back to the cmd module, and finished updating the interfaces. Everything beyond this point should be a case of switching over completely to the new interface. If I'm remembering and reading the grep output correctly, that should be relatively minor of a change. I think it should just be command and parametric_command.

...

Oof, "just".

parametric_command should be fine, but command is a bit of a mess in this area.

Here's the deal...

command defines an EnvVars type that is parametric over... stuff. It's a map from strings to... stuff. Where "stuff", in this case, is a CmdArg and either nothing else, or an Executable.

(Side note: I find myself wondering whether it's worth having the Path/NonPath distinction, but I still need the new logic to feel comfortable with this code, so let's go ahead with it anyway.)

Now, let's trace what this code is doing. Not going to touch it tonight, but let's trace it.

The type ultimately gets used by resolve_env. This function currently produces a mapping from str to CmdArg. It needs to produce a mapping from str to EnvVar[CmdArg]. Which means that _convert_segment needs to be producing EnvVar[CmdArg], which is a bit interesting, because it doesn't overlap with the other return types from _convert_segment, so I ought to be able to split it out into a new method. At that point, it makes sense to provide three private conversion methods instead of one combined one.

So, the first thing I need to do is to trace out what the other call sites do, and track down which types they need to handle.

That could be a lot. So, I'm going to wrap things up for now, and wind down.

Good night.