Thanks @David Platten . Finally managed to reduce the number of code style issues on Codacy rather than increasing them, but that was partly by just disabling more of the pylint checks! I am confident that it is a good discipline to use, but I am wondering now about ditching Codacy and setting up an alternative instead, rather than just fighting pylint all the time. Flake8 appears to be the linter tool to use, but it isn’t an option in Codacy.
And I think unless @Luuk or anyone else has a better idea or reasonable objection, I think I’ll merge the code in sooner rather than later so we can have a cleaner base to finish off the version 1 release with.
Seems to me like a very good idea to unify code formatting and I can’t think of any reasonable objection.
Should we use black before committing or would it be possible to build it in a Bitbucket pipeline?
I need to think about that. It changes the code, so might be a surprise if it happened after the code is committed. And I’m not sure how that would work.
There might be something that can be done with pre-commit hooks, not sure.
Maybe just a pre-merge check (manually)?
I’ll add some docs as to how to use black (is pretty much as default)
Manually is fine for me. Just wondered if it was (easily) possible and what you had in mind.
Reverting reformatting of skin map array. Refs #841
Refs #841 but doesn't fix it because I need to add some developer docs for black.
Runs flake8 report first, then creates code quality report for everything, then runs a quality gate check before finally running the django tests. Quality gate is currently set at a low bar for now. Not sure which of code quality or django tests are more likely to fail - whichever it is should go first to save pipeline minutes!