Coding 2022-04-10
Well, I suppose if I'd been expecting this issue, I would have accounted for it. Unless I've forgotten something, the current code is missing the ability to pass multiple—or indeed, any—Python versions into the Pip installer object, so it's not capable of actually generating the requirements.
Right now, I have two basic ideas for how to deal with this. One is to hack additional Pip objects into the code flow, so one object contains the requirements, and the other contains the version information. The other is to separate out the relevant field on the Pip class into a separate class, and make that class be an argument to Pip.resolve().
The former object is worth it if I want a bunch of flexibility. The latter option is worth it if I think I don't need all that flexibility. I don't want to choose just yet, hopefully tomorrow, so for now I'm going to try to develop the pros and cons a bit more.
The first question is, how strongly would I be committing with either choice? My feeling is the latter option puts the code into a simpler shape.
In the former case, there'd be more flexibility in terms of ways to inject the version information, but I don't see what that flexibility would help with, and it would mean two different ways to inject the information, with different overall capabilities. That sounds to me like some kind of trap for the unwary.
So, unless I change my mind, the plan for tomorrow is to rework the code and provide one interface for specifying versions.
For now, I'd like to wrap up a little earlier than I have been lately.
Good night.