Django 3.1 JSONField is missing #439
Comments
|
Yeap, |
|
I was going to put together a PR since it seemed pretty straightforward, but I'm having issues running the tests 😞 A minimal case would be like: from django.db import models
class JSONFieldModel(models.Model):
json_field = models.JSONField()Note that KeyTransform and KeyTextTransform should also be available from django.db.models.fields.json, like the PostgreSQL equivalent (just copying the existing type defs will probably work). |
|
This is not that easy. Because we still don't know how to support multiple versions of django types in a single codebase. |
What would be the impact of having the types available on |
|
One way I have seen it done in other projects with similar constraints is to branch into two versions. 1.x could continue supporting the current versions while 2.x would support Django 3.1, and changes that apply to both can be backported to the 1.x branch. An approach that is even easier to understand is to release versions that match the Django major and minor versions, with patch versions that follow incrementally from changes in django-stubs. For example, the first version of django-stubs with Django 3.1 support would be 3.1.0. If any changes are done to it, then release 3.1.1, and so on. If any of those changes apply to previous versions, release them as 3.0.(n+1) and 2.2.(n+1) too. The nice thing about this project is that most of the changes consist of declarations, which are relatively easy to backport. The main branch in any case should thus reflect the code for the highest supported version of Django, with separate branches supporting the previous versions. |
|
@federicobond yes, I guess it is the easiest way. |
That's basically the pattern used by the TypeScript definitions in https://github.com/DefinitelyTyped/DefinitelyTyped, and it works well. |
|
We need to think about how we should handle stubs and plugin. We cannot store our plugin in different branches. |
|
@sobolevn can you clarify a bit more the requirements for the plugin and how they differ from the stubs? One possible way forward would be to extract the plugin to a different repo. |
|
Plugin is not bound to django version. Stubs are. |
|
Is there an approved workaround for this? |
|
I've been thinking a while about this and here's my idea: We could create one separate repo for stubs, having two main branches, for example Using Though, it would require user to have BTW I think we should switch from |
|
Is there a reason why releases of this project wouldn't just track the
major and minor versions of supported Django versions?
On Sat, Aug 22, 2020 at 7:43 PM Kacper ***@***.***> wrote:
I've been thinking a while about this and here's my idea:
We could create one separate repo for stubs, having two main branches, for
example master for 3.1 and newer, and legacy for pre-3.1. One of the
branches should be pulled from the repo during install, in the similar way
as we pull Django source code in scripts/typecheck_test.py at this moment.
Using pip functionality --install-option docs here
<https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-install-option>
we could give users availability to choose if they'd like to use pre-3.1
stubs, with 3.1 and higher as default (no --install-option used). So, the
command for pre-3.1 would look like this:
pip install --install-option="--legacy" django-stubs
Though, it would require user to have gitpython package installed before
installation starts, so adding it to dependencies is not enough. I'm not
sure how we could resolve it.
BTW I think we should switch from distutils to setuptools in setup.py,
shouldn't we?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#439 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABY3VN2QUFSHI6FZJMR6XTSCBJ2ZANCNFSM4PVZJAAQ>
.
--
Robert Elwell
http://robertelwell.info
|
|
@relwell Yes. The plugin itself is far from perfect, and user who would like to use Django Stubs with Django 2.2 would get a buggy plugin delivered, with no hope for improvement. |
|
I'm not sure I understand. Each branch would track a combination major and
minor version, and releases would be generated from each track. You could
use the patch version of each release to provide bug fixes or improvements.
I'm not sure this project needs separate repos. It just needs a different
branching and build strategy.
On Sat, Aug 22, 2020 at 8:01 PM Kacper ***@***.***> wrote:
@relwell <https://github.com/relwell> Yes. The plugin itself is far from
perfect, and user who would like to use Django Stubs with Django 2.2 would
get a buggy plugin delivered, with no hope for improvement.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#439 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABY3VIPM2IS7KWZ3LA6WVDSCBL6BANCNFSM4PVZJAAQ>
.
--
Robert Elwell
http://robertelwell.info
|
|
@relwell In that case if someone report an issue with plugin, we would have to apply it to either major and minor branch. This would generate twice as much PRs to review, and could cause a danger that plugin would work differently at major and minor version in case someone forgets to apply change to both branches. It's not about the stubs really, missing stub will generate an error, while bug in plugin might crash Mypy (or generate nonsense type annotations either). |
|
Fair enough! Pinning related versions is a pretty common practice in
"ecosystem" libraries like this (see Kotlin Gradle plugins, for example).
The approach does require a great deal of support and maintenance. Since it
encourages explicit version pinning between related dependencies, I'm
confident it would solve the problem you're experiencing decisively,
scalably, and without needing to fork. It's important that the approach
works for the maintainers, though.
I'll look forward to seeing the solution you all arrive on 🙂
On Sat, Aug 22, 2020 at 8:12 PM Kacper ***@***.***> wrote:
@relwell <https://github.com/relwell> In that case if someone report an
issue with plugin, we would have to apply it to either major and minor
branch. This would generate twice as much PRs to review, and could cause a
danger that plugin would work differently at major and minor version in
case someone forgets to apply change to both branches. It's not about the
stubs really, missing stub will generate an error, while bug in plugin
might crash Mypy (or generate nonsense type annotations either).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#439 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABY3VIAIFYT73RENPTO32DSCBNHLANCNFSM4PVZJAAQ>
.
--
Robert Elwell
http://robertelwell.info
|
|
@kszmigiel let's discuss this tomorrow! |
|
Hi there, I was wondering if there has been any update on this issue? I understand there's no perfect solution to this, but it'd be a shame if the last features of django aren't supported because of backwards compatibility issues... Happy to help if I can! |
|
See #262 |
|
@niksubramanian Hello! Me and @sobolevn actually worked out a plan of making it work. We plan to divide stub files into separate repositories, as there is no simple solution to support various Django versions. It'll be done as soon as I finish my refactor, which lingers in time due to my excess of responsibilities. I'll get back to this, promise. |
|
@kszmigiel awesome! Thanks so much for all the hard work you're putting in the library - it has saved us countless hours of bug hunting, so it's very much appreciated. |
|
I experienced this bug when upgrading a project from Django 2.2 to Django 3.1 and I want to share my feelings and feedback. I don't want to sound harsh but this makes me regret adding django-stubs and mypy to the project I'm working on, I wouldn't have done it if I had known about this beforehand. It's a project with several other programmers, with varying degrees of experience with Python, Django and MyPy, so I try to make the development experience as smooth as possible. Now if they use some Django 3.0 or 3.1-specific features such as I like @federicobond's idea of versioning the stubs to match the supported Django version, and backporting changes as necessary. However I recognize that might bee too cumbersome to maintain. In that case I like @kszmigiel's idea of having two branches:
I think the two-branch approach would cover all bases except users not on Django LTS and not on latest Django version. In my opinion those users could just pin django-stubs version to avoid upgrading until they upgrade Django. Last comment was from October, can someone please give an update on whether this issue will be fixed or not, and if there is something I can do to help it get done? Thank you for all your work on |
...until it is added to stubs. See typeddjango/django-stubs#439
This is a bit annoying. Django says the old way is deprecated. django-stubs doesn't know about the new way. This uses the new way while ignoring the typing error. See: typeddjango/django-stubs#439 Fixes: #1698
Bug report
What's wrong
Django 3.1 adds a generic
models.JSONFieldandfields.JSONFieldto replace the PostgreSQL-only versions:https://docs.djangoproject.com/en/3.1/releases/3.1/#jsonfield-for-all-supported-database-backends
Attempting to use these new fields results in
error: Module has no attribute "JSONField"How is that should be
Type definitions should exist for the new imports. These can probably just be copied from the existing PostgreSQL versions.
System information
pythonversion: 3.8.5djangoversion: 3.1mypyversion: 0.770django-stubsversion: 1.5.0The text was updated successfully, but these errors were encountered: