Repository navigation
Home
Which of your dependencies block a Django upgrade, and in which order to upgrade them.
django-upgrade-report reads your lockfile, asks PyPI what every Django-related package declares, and gives you the upgrade plan: blockers first, then the smallest safe step for each package, in the right order. When the new Django needs a newer Python, it checks every dependency on that Python too.
uvx django-upgrade-reportThis wiki is the manual. The README is the short tour; here every option, rule and output is explained in full.
| If you want to | Read |
|---|---|
| Run it on your project for the first time | Getting started |
| Understand a row of the report | Reading the report |
| Know why a package got its verdict |
How it decides, then --explain
|
| Move to a newer Python as well | Upgrading Python |
| Use lockfiles, forks or a private index | Dependency sources |
| Run it in GitHub Actions, GitLab or pre-commit | Continuous integration |
| Look up an option | Command-line reference |
| Process the JSON report | JSON report reference |
| Look up an input of the GitHub Action | GitHub Action reference |
| Fix something that does not work | Troubleshooting |
| Change the code | Architecture |
The report shows what maintainers declare, not whether your tests pass. Use it to plan the upgrade, then run django-upgrade on your own code and your test suite with python -W error::DeprecationWarning.
Only the names and versions of packages that come from PyPI are sent to PyPI; your code, git and path dependencies and packages from a private index stay where they are (see Dependency sources).
django-upgrade-report · MIT · by Daniel Kurdoghlian, Pushing Pixels · This wiki is generated from docs/wiki/: change it with a pull request.