[x] Add support for imports inside an if TYPE_CHECKING block. Implement in LibCST if accepted otherwise here.
For now, imports will be added using AddImportsVisitor. Following what is done in Instagram's monkeytype tool, will add a option to move them in an if TYPE_CHECKING block using their own MoveImportsToTypeCheckingBlockVisitor.
[x] Investigate if using the generic syntax on the Foreign field is possible (__class_getitem__ might not be implemented yet)
Two options, either patch installed stubs, or make a local copy in a local stubs folder (e.g. ./typings/ for pyright, use mypy_path for mypy). If a local copy, should untouched files be symlinked?
Program could run in the background and watch for file changes. If stopped, should it reset the stubs to their original state? Also look at how django watches for changes, might hook it in there. In the end, might be a django app used in development: no need to setup django and patch sys.
Features:
Add overloads for related fields, by annotating self: Field[..., ...]. It seems to be possible to import models in stubs.
Add overloads for manager methods, e.g. filter: annotate self: BaseManager[Model] and handle custom querysets/managers (tricky stuff, users will need to explicitly annotate objects for it to work. How to handle objects = CustomQuerySet.as_manager()?)
Dynamic stubs for settings
^ This is now partially implemented, progress is tracked in separate issues.
if TYPE_CHECKINGblock. Implement in LibCST if accepted otherwise here. For now, imports will be added usingAddImportsVisitor. Following what is done in Instagram's monkeytype tool, will add a option to move them in anif TYPE_CHECKINGblock using their ownMoveImportsToTypeCheckingBlockVisitor.__class_getitem__might not be implemented yet)DJA001
Implement support for relative model importASSIGN_FOREIGN_FIELDcould take into account calls toFieldwith dict unpacking, although really not common:Field(**{"to": "Model"})More tests (e.g. test self relationship)Add support for duplicate model names in different apps (see how it is handled for dynamic stubs).Moved to https://github.com/Viicos/django-autotyping/issues/21
Dynamic stubs
Only
django-stubswould be supported.Two options, either patch installed stubs, or make a local copy in a local stubs folder (e.g.
./typings/forpyright, usemypy_pathformypy). If a local copy, should untouched files be symlinked?Program could run in the background and watch for file changes. If stopped, should it reset the stubs to their original state? Also look at how django watches for changes, might hook it in there. In the end, might be a django app used in development: no need to setup django and patch sys.
Features:
self: Field[..., ...]. It seems to be possible to import models in stubs.filter: annotateself: BaseManager[Model]and handle custom querysets/managers (tricky stuff, users will need to explicitly annotateobjectsfor it to work. How to handleobjects = CustomQuerySet.as_manager()?)^ This is now partially implemented, progress is tracked in separate issues.