2024 TODOs

[jared321]

• See template_repo Issue 4 and include Issue Split flake8 and black in tox.ini #100 in that
• Work with the optimizers to start building up a documentation structure/strategy (e.g., Developer’s guide that includes info about tox)
• Should we have a POptUS python package that provides, for instance, a logging interface?
• Learn from Steve and John-Luke about using python mutable objects and classes wisely for this type of programming
• Determine if submodules is the way that we should progress with this project. If not, then what? If so, then should we have scripts that help non-git-saavy users work with submodules correctly?
• Design scheme for automatically logging run information for the purpose of traceability and reproducibility.

[jared321]

@jmlarson1 I see that you now have a GitHub action for running black on updates to pull requests. If all the python files pass flake8, then why do they also need to make black happy?

[jmlarson1]

Black is certainly more restrictive than flake8, and I'm fine with relaxing the running of black for PRs. I do think it's nice to know/see. (We can pull in without black passing, though.)

[jared321]

Does that mean that the PR will show a failure with the red "X" and we would just ignore that after checking that the failure is only due to the black CI action? If so, do we want to have caveats tied to the interpretation of CI results?

My two cents is that black is too restrictive. It wouldn't be an issue except that I don't like the idea of a tool changing my code unless I can be certain that I can check its changes, and black can make that more difficult because it can make many "insignificant" changes. What if there are method developers like me that don't want to adhere to/use black?