Expected release of 3.15.0

[amitkma]

Hey maintainers, we would like to know when we can expect the new release to support DRF 3.15.?

[cjwatson]

And also mypy 1.10 (f141057); this is important since django-stubs 5.0.0 was just released requiring 1.10, so trying to depend on mypy; django-stubs[compatible-mypy]; djangorestframework-stubs[compatible-mypy] now results in a very strange solution involving djangorestframework-stubs 1.4.0 (since that was the last release without an upper bound on mypy).

[intgr]

Hi! Yes, now that django-stubs 5.0.0 is out, I'm planning to release djangorestframework-stubs too shortly.

trying to depend on mypy; django-stubs[compatible-mypy]; djangorestframework-stubs[compatible-mypy]

Indeed, that's not a good idea. Please use the compatible-mypy extra of only one package at a time. E.g.

• django-stubs[compatible-mypy]; djangorestframework-stubs
• or django-stubs; djangorestframework-stubs[compatible-mypy]

[cjwatson]

Indeed, that's not a good idea. Please use the compatible-mypy extra of only one package at a time. E.g.

Useful hint, thanks. It would be helpful if that were documented somewhere.

[allanlewis]

trying to depend on mypy; django-stubs[compatible-mypy]; djangorestframework-stubs[compatible-mypy]

Indeed, that's not a good idea. Please use the compatible-mypy extra of only one package at a time. E.g.

• django-stubs[compatible-mypy]; djangorestframework-stubs
• or django-stubs; djangorestframework-stubs[compatible-mypy]

Why so? Poetry resolves it fine and I would expect that to ensure that the stubs packages and Mypy are mutually compatible.

[intgr]

It's done!

• Release notes: https://github.com/typeddjango/djangorestframework-stubs/releases/tag/3.15.0
• PyPI: https://pypi.org/project/djangorestframework-stubs/3.15.0/#history

[intgr]

Why so? Poetry resolves it fine and I would expect that to ensure that the stubs packages and Mypy are mutually compatible.

If you install djangorestframework-stubs[compatible-mypy], it has a transitive dependency on django-stubs[compatible-mypy] to ensure mutually a compatible mypy version anyway.

The issue with adding too many dependency constraints is that there are frequently many valid solutions to given contraints -- which can include a DRF-stubs release from 2021 -- but only one of the many solutions is actually the one you expect. Thus you are at the mercy of pure luck or possibly constraint solver heuristics to pick the right one.

Also Poetry uses your existing poetry.lock as a hint and probably tries to prevent downgrading. But this means that someone installing from scratch, without a lockfile, may get a different experience -- I am not sure.

[intgr]

But this means that someone installing from scratch, without a lockfile, may get a different experience -- I am not sure.

Indeed, I tried with an empty Poetry virtualenv:

mkdir a
cd a
poetry init -n
poetry add 'djangorestframework-stubs[compatible-mypy]<3.15' 'django-stubs[compatible-mypy]' mypy

Output

Using version ^5.0.0 for django-stubs
Using version ^1.10.0 for mypy

Updating dependencies
Resolving dependencies... (0.3s)

Package operations: 21 installs, 0 updates, 0 removals

[...]
  - Installing django-stubs (5.0.0)
  - Installing mypy (1.10.0)
  - Installing djangorestframework-stubs (1.4.0)       <-- (?!)

[allanlewis]

Why so? Poetry resolves it fine and I would expect that to ensure that the stubs packages and Mypy are mutually compatible.

If you install djangorestframework-stubs[compatible-mypy], it has a transitive dependency on django-stubs[compatible-mypy] to ensure mutually a compatible mypy version anyway.

The issue with adding too many dependency constraints is that there are frequently many valid solutions to given contraints -- which can include a DRF-stubs release from 2021 -- but only one of the many solutions is actually the one you expect. Thus you are at the mercy of pure luck or possibly constraint solver heuristics to pick the right one.

Also Poetry uses your existing poetry.lock as a hint and probably tries to prevent downgrading. But this means that someone installing from scratch, without a lockfile, may get a different experience -- I am not sure.

Sure, but in my situation I'm working on an app, not a package, so I pin everything in my pyproject.toml. With regard to this package and friends I pin django-stubs, djangorestframework-stubs, and mypy to the versions I want and then ensure that Poetry can find a resolution. I always check the lock-file diffs as well.

Given I'm using Django 4.2 and DRF 3.14 I pin django-stubs to 4.2.7 and djangorestframework-stubs to 3.14.5. I also pin mypy to 1.7.1 as I know that's the declared compatible version. This works for me, although I'd appreciate looser constraints on the compatible-mypy extra.

Given typeddjango/django-stubs#2101 (comment) I'll probably now remove compatible-mypy entirely and rely on CI to tell me when things aren't working.