Three Dollar Quill

Right now, I'm pondering a change in my project structure. Basically, when I was basically propagating my tooling by mass copy/paste, it more-or-less made sense to encode a bunch of ideas about "here's how to do things" in data files that aren't part of any explicit configuration.

To be more specific: In a lot of my projects, I have a top-level requirements directory that contains several requirements.txt-type files, meant to be installed in specific circumstances. But I just checked, and most of them are only like that in some kind of attempt to "streamline" the noxfile, so I can replace "install this and this" with a single filename.

Now, this is a bad fit for the paradigm I'm aiming for with MOTR, because the high-level abstractions I'm writing are connecting an installation task to a script that they expect the task to make available. In effect, this is asking any consumers to put a file in a specific place, and also put specific things in that file. In the majority of cases, the onus to do all of this could be entirely removed by just putting the requirement data into the code, and expecting any project-specific fine-tuning to be in a constraints.txt file. In the remainder of cases, the required work could be somewhat diminished. These cases are when there are additional plugins that can be installed to augment the functionality of a script. I mainly have this use case for running flake8, maybe mypy, and sometimes pytest.

So, here's what I think I'm leaning towards:

• The user can provide a top-level constraints.txt file that covers most details of version/source to install.
• The build step generates an additional constraints.txt file that references the user-provided file, if given.
• In addition to the package name, the environment creation flow can take a path to a supplementary requirements.txt file, relative to the root. This file does not need to specify the base package name, but doing so shouldn't hurt anything.

Now, an additional thing I'll need to work on is plugin code that requires command line arguments. I can't gloss over that, which means that some of this is going to live in code rather than as requirements files.

Let's see what that looks like:

• flake8-isort needs code-level support
• as does flake8-html
• The --html-report flag for mypy needs code-level support.

Thinking over this, here's what I think makes sense:

• Make the Input and Output classes more flexible in what they can contain, and allow specifying both in the freeform section of the cmd helper function.
• Cut a new release so I can confirm that this simplifies writing the higher-level abstractions.
• Remove some hackery from the cmd function.
• Cut another new release to confirm that didn't break anything. (I may be able to condense these into one release.)
• Write initial documentation of everything, since there's about to be a lot more code in there.
• Outline and fill out the new constraints.txt way of doing things.
• Migrate the motrfile from the old to the new way, including deleting the old code.
• Start pulling code from the motrfile into MOTR.
• Figure out how I want to organize the different abstractions in the api module.

Good night.