2024 TODOs - Githubissues

POptUS / IBCDFO

Interpolation-Based Composite Derivative-Free Optimization

Other

7 stars 2 forks source link

2024 TODOs #122

Open jared321 opened 11 months ago

jared321 commented 11 months ago

[ ] See template_repo Issue 4 and include Issue #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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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?