Develop a strategy for managing versions of esap-api-gateway dependencies
esap/requirements/base.txt specifies a number of very precise versions of dependencies. No information is recorded about why these particular versions were chosen. Some of them are now getting pretty old, and will start to become obsolete, or even to have security flaws (e.g. we have a hard dependency on Django 3.1.4, while I see CVE-numbered security fixes in 3.1.6, 3.1.7, 3.1.8, 3.1.9, .. etc — I've not looked at what each of those problems is, but on the face of it that's pretty scary!).
We need to:
- Audit the existing list of requirements and figure out what the rationale for each of those hard numbered dependencies is — do we really need to be locked to these versions?
- Develop a policy for how we manage these dependencies going forward, which combines staying current with upstream development with appropriate due-diligence to ensure that doesn't break our code.