Three Dollar Quill

Okay, after the last entry, I drafted out a test using the not-yet-written modules that will be needed. Some of it will need to be updated to match the interfaces, but first, there's something pretty serious that I need to work on.

Recently-ish, I was having trouble accounting for the different Python versions that will be used by the various commands. At the time, I punted on them, by pulling them out of some of the higher-level data structures, and making them a parameter to the map method.

As has been kind of a recurring thing, I'd forgotten part of the design goals. The choice of interpreter is supposed to be recapitulated by the FlexIn object, which means it has to be stored under a ParametricLabel[PathWith[VirtualenvArgs]] in the Registry. I didn't work on this earlier today, but let's see if I can put together a quick sketch of what this would entail, in the next fifteen minutes or so.

Right now, the data is injected like so: lambda command: command.requirements(python). After the changes, that site is going to look like lambda command: command.requirements() (or potentially just passing the unbound method). An additional line will need to be added to get the relevant data into the registry.

So, let's have a look at the requirements() method...

Hm. I'm not seeing a way to dramatically change this part of the code. I think I need to look into the ParametricCommand class. That's where I thought this stuff was supposed to live, I think. That's the level of code that handles injecting information into the Flex objects, so let's see...

One possible way in is a pre-processing step in ParametricCommand.build(). Let's see where that's called from...

python_helpers.CommandBuilder.parametric() From an API perspective, this looks like an excellent place to add an argument for this purpose. Now, it's just a question of figuring out what that argument looks like...

So, here's what I've got:

• ParametricCommand.build() gets some kind of new argument, and takes on responsibilities to code that argument so ParametricCommand._build() can use it, and process the result of ParametricCommand._build() so that the outer function now directly handles the requirements() call.
• Parametric.map() gets trimmed down and renamed.
• python_helpers.CommandBuilder.parametric() gets a new argument.

I'm not done sketching this out, but I think I'm done for the night. I want to try and cool off.

Good night.