Update dependencies (django 2.2 > 4.2)

[nougad]

This repository requires django 2.2 which is out of security support since 2022-04-01 ( https://endoflife.date/django )

I updated the project to latest django 4.1 together with some other smaller cleanups: https://scm.indeedgeek.de/flo/nsupdate.info/commits/branch/master

The project here seems not very active and I'm not sure if it's worth creating PRs for all changes. Especially since I did some modifications to make upgrades easier on my side (Pipfile, pylint, testing in docker, ..) which might not be welcome. But I wanted to give folks a heads-up in case there is demand in taking over my work.

I'm not very familiar with django but run the updated version since 2 months with my fairly small production workload without problems.

[ThomasWaldmann]

Thanks for working on upgrading the stuff, that would be a really good contribution if you could make a PR from that.

I have looked through the changes, some comments:

• I don't like docker much, but if it helps with testing this locally, it might be worthwhile to add it to the workflow. I did not understand precisely why you needed to add it though.
• automated dependency upgrades by a bot: is that useful? usually that stuff will need review and testing (sometimes manual testing, like when updating fonts, css, ...) and sometimes changes to the src a bot can not provide, so what is the point?
• pipfile - i don't use that yet, what is the advantage? what i've seen from your changesets, you now need to edit requirements at one more place than before.
• python-build: didn't use that yet either, what is the point?
• getting rid of all python2 stuff: sure, of course.
• testing: should be (also) done on minimum requirement of the project, not (only) with py311

What's especially interesting for me is whether / how you tested the upgrade from the previous code / previous databases (sqlite3).

On https://nsupdate.info/ there are quite a lot of users, so upgrading from the current database / current code to the new one should not cause too big problems.

[nougad]

1. I don't like docker either. But without it it's really hard to run the tests since the tests want to manage a dns server on 127.0.0.1:53 which needs to be configured correctly. Docker is still not great because I could not get all tests to run successfully, but at least it allows me to run some of the tests without relying on travis. I limited the docker usage to a single commit. If you don't like it exclude it when merging.
2. I think updating all dependencies every week and automatically running all tests is huge gain. I don't want to run any project without it anymore. But my renovate setup is special and I will exclude it from the PR. Nevertheless I would suggest you to give github's dependabot a try.
3. requirements.txt does not track transitive dependencies. Pipenv helps with this and also provides some nice wrapper so you don't need to fiddle with virtualenv. I include the pipenv in the setup but I don't want to force my tools on you so if you don't like it remove it afterwards. There is also a mode to keep both (Pipenv for development and requirements.txt for deployments) by generating requirements.txt out of the Pipfile (mentioned in the DEVELOPMENT.md file).
4. pyproject-build is packaging the wheel files for publish with twine to the python package registry. If you have other tooling that's fine but since nothing was documented I used what was available.
5. I did not touch the travis part. I assume it still works but I can't verify it. The python version should be only set in Pipfile for local tooling and Docker for local testing. Both should be independent of the CI/CD setup.
6. Other than the local testing I only run with postgresql and had to add one database adjustment: https://scm.indeedgeek.de/flo/nsupdate.info/commit/5593eec2d8660b6be237db40c9af57216f5bc7f3

I created the PR at #505

[ThomasWaldmann]

1. ok
2. yes, we can add that in a future PR (if it does not want too much permissions, i don't like to give repo r/w to 3rd parties)
3. ok
4. we did not have wheels yet. why would we need wheels now? iirc there is nothing needing a compiler here, nothing "binary".
5. travis CI is likely broken / inactive since they long. i got rid of it for most of my other projects and migrated to github actions.
6. ok. looks fine. having it practically tested on postgresql and sqlite would be great before we try that on the production system.

Thanks for the PR!

[ThomasWaldmann]

@elnappo could you review this? -> #505

[ThomasWaldmann]

Half of that upgrade is already live via #516.

[ThomasWaldmann]

Other half is WIP, see #517.

[hensing]

Thank you @nougad for the initiative and @ThomasWaldmann and @elnappo for the review <3 was looking forward to this but was too novice with django myself ...

[ThomasWaldmann]

Try 2: see #529

[ThomasWaldmann]

OK, Django 4.2.x is life at the production site, so guess we can close this.