Reminder: Adopt the HyperModern Python Architecture & Tooling

[tdonaworth]

We need to fold these items into user stories:

• [ ] Dependency Management should acknowledge and adhere to the future state of Python [PEP 517, PEP 518]
• [ ] Organize the project into a manageable structure that makes sense, and meets industry standards.
• [x] The project should use a common and portable Testing library
• [ ] The project should have the ability to quickly and easily run Tests under multiple conditions.
• [ ] The project should have the ability to check the code for common issues, and maintain readability via Linters
• [ ] Maintain a level of readability and capabilities for automated documentation, by discussing the implementation of Type annotations and checking

---

Tasks

• [ ] Pipenv vs. Poetry - Discuss, document, and implement.
• [ ] Implement the /src layout structure - Ref
• [ ] Implement and flush out options/configurations for PyTest
• [ ] Implement and flush out options/configurations for Nox
• [ ] Implement and flush out options/configurations for Linters (Flake8, Black, etc)
• [ ] Discuss the need or use for Type annotations within the code, along with Type checking
• [ ] Determine a suitable documentation format (code specific), along with defined format (Python docstrings)
• [ ] Ensure API documentation is setup and working with existing API endpoints.

Additional Context & Resources

The gist of it is HyperModern Python. Open to simply rebasing the project from one of the cookiecutter projects

[xlorepdarkhelm]

Something to note:

The current process we use with nox and precommit puts things like black, mypy, & flake8 (etc) in the nox world. However the HyperModern Python process has those in the precommit. And, has it that when precommit runs, it validates with, let's say, black. Black makes changes, and it kicks back the attempted commit. Re-running the commit then automatically has the newly formatted code and black won't reject it then. And, on commit, you then would need to fix linting errors beforehand.

Currently, it requires an extra step of running nox. Which means the developer has 1 extra thing to remember. Not a huge deal, but when there's a lot of little steps to remember for things (like manually using the docker-compose.e2e.yml when running e2e tests), it can be easy to forget, which can slow down the process of getting a PR ready for review.

I would propose that nox be left for testing, and all linting/code formatting/etc be put into the precommit hooks instead. The template of this exists in the HyperModern Python Cookiecutter. Uses the same tools we basically are now, just organizes it a bit differently.