#372 - [GH-ISSUE #504] Update dependencies (django 2.2 > 4.2) - starred/nsupdate.info-nsupdate-info

kerem commented

2026-02-26 10:31:08 +03:00

Owner

Originally created by @nougad on GitHub (Mar 12, 2023).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/504

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.

Originally created by @nougad on GitHub (Mar 12, 2023). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/504 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.

kerem closed this issue

2026-02-26 10:31:08 +03:00

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Mar 12, 2023):

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.

@ThomasWaldmann commented on GitHub (Mar 12, 2023): 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.

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@nougad commented on GitHub (Mar 18, 2023):

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.
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.
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).
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.
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.
Other than the local testing I only run with postgresql and had to add one database adjustment: scm.indeedgeek.de/flo/nsupdate.info@5593eec2d8

I created the PR at https://github.com/nsupdate-info/nsupdate.info/pull/505

@nougad commented on GitHub (Mar 18, 2023): 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 https://github.com/nsupdate-info/nsupdate.info/pull/505

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Mar 18, 2023):

ok
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)
ok
we did not have wheels yet. why would we need wheels now? iirc there is nothing needing a compiler here, nothing "binary".
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.
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 commented on GitHub (Mar 18, 2023): 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!

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Mar 18, 2023):

@elnappo could you review this? -> #505

@ThomasWaldmann commented on GitHub (Mar 18, 2023): @elnappo could you review this? -> #505

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Apr 12, 2023):

Half of that upgrade is already live via #516.

@ThomasWaldmann commented on GitHub (Apr 12, 2023): Half of that upgrade is already live via #516.

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Apr 13, 2023):

Other half is WIP, see #517.

@ThomasWaldmann commented on GitHub (Apr 13, 2023): Other half is WIP, see #517.

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@hensing commented on GitHub (May 2, 2023):

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 ...

@hensing commented on GitHub (May 2, 2023): 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 ...

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Jul 11, 2023):

Try 2: see #529

@ThomasWaldmann commented on GitHub (Jul 11, 2023): Try 2: see #529

kerem commented

2026-02-26 10:31:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Jul 11, 2023):

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

@ThomasWaldmann commented on GitHub (Jul 11, 2023): OK, Django 4.2.x is life at the production site, so guess we can close this.

Rows
Columns

[GH-ISSUE #504] Update dependencies (django 2.2 > 4.2) #372