## TL;DR
Never revert one package alone when two packages constrain each other. Put Django and djangorestframework into a single resolver run, upgrade DRF to a version that supports Django 5 first, then bump Django with it. The revert-bump-revert cycle is the agent solving two linked constraints one at a time; a joint solve ends it.

## The query

```text
agent bumped django 4.2 to 5.0, then djangorestframework demanded django<5, so it reverted django and broke djangorestframework again
```

## Use this when

- The agent's history shows Django and DRF versions oscillating
- The error mentions a `django below 5` pin coming from djangorestframework
- The agent already tried bumping then reverting at least once
- DRF was upgraded separately from Django in the same task

## Not for

- `ImproperlyConfigured` or other Django config errors after a clean upgrade
- General pip `ResolutionImpossible` with no DRF involvement
- A Django upgrade blocked by a different package's pin
- Lockfile or merge conflicts from the upgrade PR

## Steps

### 1. Read the actual constraints

Run `pip index versions djangorestframework` or check DRF's release notes to find which DRF version first supports Django 5.0 (3.14.x and later support Django 5.0). Write down the pair that works: Django 5.0 + DRF 3.14+.

Expected output: a known-good version pair, e.g. `django==5.0` with `djangorestframework>=3.14`.

### 2. Upgrade the dependent package first

Install DRF to the Django-5-compatible version before touching Django: `pip install "djangorestframework>=3.14"`. DRF is the package with the pin; satisfying its constraint first removes the blocker.

Expected output: `pip` resolves without a `django below 5` conflict.

### 3. Install both in one resolver run

Run `pip install "django==5.0" "djangorestframework>=3.14"` in a single command so the resolver sees both constraints together. Do not let the agent do them as two steps.

Expected output: a consistent install with no `ResolutionImpossible`.

### 4. Freeze the pair in the lockfile

Commit the lockfile or constraints file with both pins. Add a comment near the DRF pin noting it must stay on a Django-5-compatible line, so the next agent run does not "helpfully" downgrade it.

Expected output: the lockfile pins both, and the comment survives the next agent pass.

### 5. Run the real test suite before declaring victory

Run the project's full test suite, not just DRF's imports. Django 5.0 removed some APIs (check the release notes) that DRF 3.14 handles, but your own code may not.

Expected output: green suite, or a short list of your own code's Django-5 incompatibilities to fix.

## Variant phrasings

### agent reverted django and broke djangorestframework

Same fix. The revert is the failure mode; ban single-package reverts in the agent's upgrade config.

### djangorestframework requires django<5 after upgrade

Steps 1 and 2 are the whole fix: the installed DRF is too old. Upgrade DRF first.

### django 4.2 to 5.0 upgrade breaks rest framework

Check first whether you actually need Django 5.0 now. If you do, steps 1-3. If DRF cannot go past 3.13 in your setup, you do not have a supported Django 5 pairing yet.

## Why it happens

DRF declares an upper bound on Django for each release line. The agent bumps Django alone, the resolver sees DRF's `django<5` pin, and the agent "fixes" it by reverting Django. Then DRF's newer code (or the agent's next pass) wants Django 5 features and breaks on 4.2. Each move is a valid local fix for one constraint while violating the other. The agent never holds both constraints in its head at once.

## Edge cases

- DRF cannot be upgraded (internal fork or pinned by another package): then Django 5.0 is off the table for now. Say so explicitly instead of looping.
- Third-party DRF extensions (django-filter, drf-spectacular): they have their own Django/DRF compatibility lines. Include them in the joint solve in step 3.
- Django 5.0 dropped support for Python 3.10: check the Python version before any of this, or the joint solve succeeds and the app fails to boot.
- The agent's cache: a warm pip cache can mask a bad resolve. Verify with a clean virtualenv (`python -m venv /tmp/verify && pip install -r requirements.txt`) before merging.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sYQdw7E4URtsErGHiMqXeg