Coding 2021-09-20

By Max Woerner Chase

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:

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:

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

Good night.