I managed to give myself kind of a rough day today, so I just focused on exploratory prototyping for MOTR. Just, like, zoning out a bit, translating notes to code.
Basically... MOTR runs a bunch of commands, and those commands can be decomposed into distinct parts that carry installation requirements in order to work. So, I've got prototype Fragment and Option classes. A Fragment is either a complete command (just requiring a bin directory prefix), or an invocation of a Python module. (This may open up as I look into working with other kinds of command.) An Option is a sequence of command-line arguments or environment variables, along with associated requirements. From a runtime perspective, they are nearly the same, except that Fragments have an optional field that allows them to combine with another Fragment, if the field is not None. An Option can be added to the end of a Fragment or Option. In the prototype, this is pretty loosey-goosey, at least at runtime, but I've got a sketch of type-level stuff that should do the right thing, more or less.
Now that I've got something that can be fed into some kind of environment preparation function, I need to design that function. Focusing on virtualenv for now, here are the axes of variation:
- Which Python version gets installed
- Which constraints file to use
And the different stages:
- Creation subsumes the "update" step from the current working version, because virtualenv bundles the latest pip.
- Installation is much as the current version, I think.
- Running is added; because the command and the requirements are built in parallel, there's no reason to hold off on running the command.
As a result, all of the stages should collapse into a single invocation from the perspective of the code at large.
The main thing I need to figure out is how to handle specifying the constraints file. The design problem arises from the fact that I want to specify environment variables, and I want to build an install command, but the constraints file is the only environment variable that I want to pass to the install command. I suppose one way around this would be to check if the bug I filed against pip is still open... Yep, there it is. Looking over Flit's source code, I believe it's currently safe for me to use the command-line options for constraints files. This is probably the way to go, just punting on addressing the design. Either I'll come up with a design, or the pip issue will get triaged. One of those has to happen before 1.0, but I'm not there yet.
Anyway, I think tomorrow I'll put the design on hold, and try to come up with a plan for making releases not have like seven steps or whatever.