Three Dollar Quill

I feel like I wasn't really focused today, so instead of trying to write code, I'm going to go over the prototype in more detail, and relate it to the current work-in-progress. So, the current current work-in-progress is capable of locating a configuration file through various means, and executing it. The basic details of that are:

• In writing tests, I have come to suspect that my design for the location logic is flawed, and tries to do too much, but I'll hold off on messing with it for now. I'll put in an issue for myself to revisit it, though.
• Currently, the configuration file is executed as Python code, and relies on API calls that don't exist yet. My long-term plan is to see what capabilities I require, and switch to a more restricted configuration language that satisfies my requirements.

Anyway, it can figure out which directory the configuration file is in, and I'm currently planning to have it change to that directory once it finds it.

That said, once the configuration is loaded, there are two basic things to be done: either print out various helpful bits of information, or, by default, execute the desired tasks.

To handle this, the prototype uses a "registry" object that contains various mappings and sets. These use strings (for several different purposes), and types called "Actions" and "Targets". Basically, Actions can have names (for diagnostic purposes) and Targets can have names (for selection/deselection purposes). Every Target has an associated Action, and an Action can be associated with any number of Targets. An Action is a Callable with a particular signature, and Target is somewhat less defined.

Basically, as inspired by various build systems (and to be clear, I do not consider this project a build system), a Target will usually correspond to a filesystem path, though this is a matter of convenience and convention only. It does not normalize Targets, or do any kind of filesystem inspection. Now, a few of the Targets I'll want correspond instead to removing a file. I don't need or want much sophistication around handling, so I don't plan to represent "delete this file" in a way the code can explicitly reason about, but I do think it'd be helpful to natively support pathlib objects, so I'd maybe like some kind of wrapper. Might be as simple as "here's a trivial wrapper class around paths, go wild".

I don't know if that's enough to start with; maybe I need to think about this some more, but I should be ready to firm up the design soon.

It somehow got really late while I was writing this, so I should wrap things up.

Good night.