Three Dollar Quill

I want to implement the helpers for making Fragments and Options and Builders. Rather than throwing stuff together all at once, I'm going to take a look at the kind of stuff that the current motrfile uses, since I need to replace most of that functionality. Looking over the output diagnostics, I see...

• pip install -U pip. This won't be necessary when I switch to full virtualenv instead of venv.
• pip install -r requirements/[something].txt. Part of the point of the Fragment API is to remove this specific structure; in addition, it'll be generating the pip install command implicitly.
• flake8 --format=html --htmldir reports/flake8 --isort-show-traceback src tests with allowed codes {1}. Oh no. I missed the allowed_codes concept. That's actually really important.
  • Anyway, we've got the command, flake8 with a python requirement of flake8. That's a Fragment with allowed_codes of {1}.
  • Next, there's an Option that is parameterized to produce a value in --format=html --htmldir [param] with a python requirement of flake8-html.
  • There's the --isort-show-traceback Option, which needs flake8-isort, and I'm starting to realize that I'm not sure what some of these requirements are for, per se. Looks like I'm going to need to audit my requirements files. Like, what's pygments doing in there?
  • Anyway, the last Options are the target directories, which should either be parameterized or dumped all into a single command; I think I'd prefer parameterization, because that's what I'm doing in the relevant noxfiles.
  • This command also has an Output that needs to be indicated in some way, parameterized. This Output is via the extra_io field, which can have a simple implementation.
• Next command is one of the test runs. Starting with the general test run data...
  • pytest is a module Fragment with allowed_codes of {1}. It requires pytest, and the MOTR tests have an additional dependency on oschmod, so there needs to be some nice way to indicate "extra dependencies".
  • The -p no:cacheprovider Option should be added by the default invocation of the pytest helper.
  • There needs to be an Option for the test directory, which should be parameterized.
  • Lastly, there needs to be an Option with --junitxml [param], which suggests to me that the likely helper for parameterized Output arguments should include some form of "prefix" Option data.
  • It also needs a parameterized pip requirement for getting the proper project installed.
• It's wrapping that in coverage run, and how I want to handle that is:
  • coverage run is a full Fragment from the perspective of the helpers, and it requires coverage. Its module runner code passes through the allowed codes for the underlying module; this should be the default behavior.
  • This will need an Output Option with parameterization to locate the coverage file.
• There are additional Coverage Fragments:
  • coverage combine (needs input files generated from all coverage output files combined) and produces a single Output file. This indicates something kind of subtle I need to surface from the lower layers. The Input/Output duality is not quite as clean, because we end up in a situation where each "side" could either be parameterized or not. Or they could be parameterized differently. I think the high-level abstraction here is some kind of "parameter set" that combines with a function to create a single parameterized version. It should take a subset of parameters (not sure whether it should be the Object or Sequence ones; I guess it should be Object since that's what the keys correspond to on the Builder), and default to creating Inputs, with an option to create Outputs.
  • coverage erase produces a bunch of abstract Outputs.
  • coverage html works with the Outputs from coverage combine (or limit-coverage, which I haven't set up on this project yet) to produce a corresponding HTML file
  • coverage report works on the same files as coverage html, but only produces abstract Outputs.
• There are junit2html commands, which need junit2html and map an Input to an Output file.
• Some of the noxfiles have junitparser merge lines to combine multiple Input JUnit files into a single Output JUnit file that can be used by junit2html.

I'm getting incredibly tired, so I'll just note the stuff I need to document later:

• mypy
• pyinstrument

That's not much, but I'm really tired.

Need to get to sleep...

Good night.