Ambivalence: this seems a lot like it's getting up into "layer 3" stuff (meaning: it's something you might want to solve with the expressiveness level of a programming language, rather than stacking further and further amounts of declarative special not-quite-code). But it's also potentially quite useful; if we do punt to programming tools, we lose any ability to statically analyze what's going on up there; and if we do punt to programming tools, we fragment any of our possibility for community growth up there.

Most other systems operating in this space have something like this. E.g. Guix and Nix most certainly do. That said: they also did go full in on programming language for it.

subquestion detection

• This appears to be highly entangled with any thoughts about use-time configurability.
  • Often we try to drive use-time configurability down to near zero in the content we build with this stack. (We try to reduce it down to mountpoint. And make other tools that pick things up from filesystem layout as necessary (e.g. like stow and its symlink farming, which needs only very simple detection patterns that are easily provoked).)
    • Which means we often succeed in deferring a bunch of problems...
      • ...but doesn't really necessarily mean we've solved them, per se.
• Does this imply a desire for an output format which is essentially json (or more generally, dmt), and the need to pipe it?
  • Putting that in a ware is not super high on the debuggability scale.
  • Putting it in a big literal seems kinda weird too.

technical ruminations

If we do go for this, and try to keep it at all declarative, it suggests a lot of fairly immediate and large implications:

• The InputKey type is no longer going to be remotely able to be responsible for uniqueness and non-collision.
• It's probably going to start to really behoove us to make the Input value something that serializes in a more easily extensible way than the current drafts, which try to cram it all into representations of stringprefix union and/or stringjoin struct.
  • ... but this probably depends on how we approach the dereferencing concept. If the Input is just a reference to a whole block of more info elsewhere,
• We probably will want to include both environment variables and fileset mounts in an input set.
  • Which is fun also because prefixing them them same way is probably a "nah".
    • You see where just having sexprs for this gets to be more and more attractive! What if I want an input set that has two use-time parameters, and one touches both the env var names and the path prefixes?