Closed MatthewWilkes closed 1 year ago
Resolved in #46 by generating specifc Python versions requirements files and using those for each of the build matrix versions. I preferred this approach as it allows me to use pip-tools to generate requirements files and manage my dependencies dependencies, pinning all versions in the tree. Thanks for taking the time to contribute this anyway @MatthewWilkes 👍🏻
Absolutely, totally a matter of taste there I think. Can understand why you've gone the other way. Thanks for the project and working in the open!
There is a requirements-test.txt pin file which contains pinned requirements for every dependency needed for running the test Flask server. This is derived from requirements-test.in which pins specific versions of flask and flake8, which are the only two direct dependencies. As such, the compiled requirements-test.txt file firms up any pins in those direct dependencies that are loose, such as the version of Werkzeug. The downside of this is that it crystalises environmental-specific dependencies like the use of back-ports for older Python versions.
The upshot of this is that this compilation ensures that if Flask 2.1.3 breaks due to insufficient pinning in the Pallets project then our builds will not fail, at the expense of failing to install the right dependencies for some environments, most notably Python 3.7 in the version matrix. This change removes the compilation step and installs the direct pins directly. This should restore Python3.7 runs to functionality in the Github runner and will cause test failures if Flask 2.1.3 is broken upstream in the future.
@matthew-shaw As discussed on Slack. Happy to talk over the reasoning and other options if you'd like.