Okay, I'm not going to commit to making these changes, but let's see what I'm thinking about doing in MOTR. Here's the initial code in the command.py module. EnvVars = pyrsistent.typing.PMap[str, MaybeExecutable[TMaybeExecutable]]. This relies on: TMaybeExecutable = typing.TypeVar("TMaybeExecutable", typing.NoReturn, Executable[typing.Any, typing.Any]) and MaybeExecutable = typing.Union[_cmd.CmdArg, TMaybeExecutable].
What I'm looking into messing with is to allow the map values to potentially contain a sequence of paths, and... hm. Something looks a bit fishy here. Okay, that CmdArg is _io.MaybeIO[PathStr]. So, it should be all right to say "let's add the ability to stick this in a tuple instead, and rewrite the update logic".
And then to actually use this, let's take a look at parametric_command.py It has an EnvVar class, which currently assumes that the values don't really combine. I believe to support this idea, I'd need another class that needs the tuple version of the values, or that provides an adaptor from non-tuple to tuple. Now, that part is seemingly straightforward, but let's see... So, instead of the Artifact in this new class matching the type in question, the Artifact needs to be the basic version, and the build() method needs to... um...
I regret to inform you that... I am confused.
Okay, I think it's enough to just change how single items get processed in the other class, and turn them into singleton tuples.
At this point, I'm pretty sure* that if I go through all of this stuff and carry out the "obvious steps", then this stuff "should work".
But, um, "should work" is a scary phrase.
Anyway, I want to wind down now, maybe do some more writing.