This will help to simply dependencies code complexity
I would say we aim for all stable versions of python3.
This would be tested through running tests in tox environments.
We would document as part of a readme, contribution guidelines, then in the setup.py
Describe alternatives you've considered
We could support python2.7 but why unless we find a specific dependency (which we can research based on dependencies from last year projects), we may already be a defacto python3 org (https://github.com/hackoregon/backend-examplar-2018)
Explain how this feature relates to your Hack Oregon project scope.
This lends to a strategic goal of increasing standards in backend & api workflows
Is your feature request related to a problem? Please describe. We do not as an organization define which versions of Python we support.
If we plan to create re-usable packages which can be deployed to a package repository (ie pypi), then we will need to define for testing purposes.
Describe the solution you'd like I would propose we do not include support for python 2, due to EOL announcement and ~9 months left.
https://pythonclock.org/ https://python3statement.org/
This will help to simply dependencies code complexity
I would say we aim for all stable versions of python3.
This would be tested through running tests in tox environments.
We would document as part of a readme, contribution guidelines, then in the setup.py
Describe alternatives you've considered
We could support python2.7 but why unless we find a specific dependency (which we can research based on dependencies from last year projects), we may already be a defacto python3 org (https://github.com/hackoregon/backend-examplar-2018)
Explain how this feature relates to your Hack Oregon project scope.
This lends to a strategic goal of increasing standards in backend & api workflows