Remedy bit rot

[c0c0n3]

Proposed changes

This PR upgrades most of the Python deps to fix security vulnerabilities, makes the Docker image build again and restores a working dev env on Apple silicon.

In detail, we've found a combination of Python dependencies that fixed all the security vulnerabilities reported by #736 as well as the ones below reported by Dependabot

• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/5
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/6
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/8
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/10
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/11
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/16
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/17
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/18
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/19
• https://github.com/orchestracities/ngsi-timeseries-api/security/dependabot/20

The implemented combination of deps along with some Docker file fixes make the Docker image build succeed again, which works out the issues reported by #735.

Finally, we've chosen Python deps that make it possible to set up a Python dev env on Apple silicon. The Apple dev env used to work last year, but now it was broken both on M1 and M2. This PR fixes #734 and provides a minimal Nix dev env you can use both on x86 and aarch64.

Types of changes

What types of changes does your code introduce to the project?

• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] Maintenance (update of libraries or other dependences)

Checklist

• [x] I have read the CONTRIBUTING doc
• [x] I have signed the CLA
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] I have run all the existing tests locally (not just those related to my feature) and there are no errors
• [x] After the last push to the PR branch, I have run the lint script locally and there are no changes to the code base
• [x] I have updated the RELEASE NOTES
• [ ] I have added necessary documentation (if appropriate)
• [ ] Any dependent changes have been merged and published in downstream modules

Further comments

• MacOS situation. So we've got a working dev env and can even build Docker images on Apple silicon. But some of the tests are still broken on Apple silicon. That's just too much effort to fix them, so I'm leaving that behind for now. But at least we can develop on MacOS.

• Dependency hell. This PR entailed a tremendous amount of debugging, dependency analysis, testing and fiddling. Docker layers, image tagging and caching, silly build file syntax, Linux package managers...these are 20th century solutions to dependency management. Nix and NixOS have leaped in the 21st century already offering a way out of the mess with proper dependency management and programming language support. We should consider a Nix-based build system so we can track all deps properly and guarantee proper app isolation and build reproducibility. As an added benefit, we can create tiny Docker images, even smaller than what you can do with an Alpine base.

  "Martel Open Source Software Individual Contributor License Agreement" "Contributing to QuantumLeap" "QuantumLeap Release Notes"

[github-actions[bot]]

CLA Assistant Lite bot All contributors have signed the CLA ✍️

[c0c0n3]

There are two geo-coding tests that have failed:

• https://app.circleci.com/pipelines/github/orchestracities/ngsi-timeseries-api/838/workflows/2633ac2e-d4c0-457c-af3a-30683e42ef96/jobs/5234

But those failures are actually unrelated to this PR. In fact, the coords of the points we expect have changed in the OpenStreetMap DB (51.12... vs 51.23...) This kind of thing crops up every now and then, you could blame it on whoever updates the OpenStreetMap DB, but I'd rather blame it on ourselves not being able to write proper tests that are independent of the actual coords---what we need to check is not how accurate OSM is, but rather that we're able to parse the response.