Three Dollar Quill

I've dealt with some of the soreness, so I'm doing a bit better now.

Anyway, back to some of the problems I was having with the code yesterday...

Basically, sometimes the dependencies that should exist are "obvious", but as the author of the code, I know they're not going to be picked up unless I include them explicitly.

I can think of two basic cases: the necessary Target is part of the command, or it isn't. The latter case is handled adequately by the current interface, and must be handled by a few different commands.

I can imagine a way for this to work, so I guess I'll try it...

Okay, yeah, I like this. Basically, the boilerplate was so annoying because, on some level, I knew that the required helper functions were trivial. Just a few lines of code, but it covers all of the stuff that "obviously" should be handled.

Right now, some of the helpers are missing full coverage of the interface that they wrap, but I don't want to get too distracted right now.

Actually, I'm going to need to add that coverage to handle pytest, and that's next to port, so I might as well...

Okay, I'm looking at this code and knowing that it's got all sorts of weird deficiencies, but I don't really want to fix it before I bring it into the codebase proper.

So, here's what I need to consider now:

• Am I ever going to use more than one command from a virtual environment? If not, I can simplify my helper functions considerably.
• Which of my internal names do I have the most issues with, and how can I fix them? Two big issues... For one, I named a module after one of the major classes in it, so if I instantiate that class in another module, the obvious name for the variable is... the name of the module that I had to import to instantiate the class. For another, some of the casting/coercion/whatever functions use different naming conventions for no good reason. No useful difference between the functions to_thing and as_thing. (To be clear, the functions are different, because "thing" is different. But they both perform the same action relative to their specific value of "thing".)
• I need to rewrite some of my helpers to use my other helpers; this will make some future extensions easier.
• Think about the organization of the api module. It's getting a little cramped, but, like, what kind of imports should consumers expect to need to do? Maybe I can have, like, an _api package inside, and just re-export a bunch of it in the api file.

My general feeling is that I can address a lot of this by breaking things up more, so I'll look into that later.

For now, my take on this is, now that I've gotten through the initial hurdles of "using" this code, it's showing promise, though I need to take some time once I'm done porting my noxfile, to figure out what kind of idioms make sense, since currently it's just kind of a massive stream of top-level statements and global declarations.

I'm getting tired and a little sore, so I'll start wrapping things up.

Good night.