unresolved-attribute errors for Django model fields

[aaschenbrener]

Summary

This is an expansion on the known issue: No implicit import of submodules (https://github.com/astral-sh/ty/issues/133). I've imported Django models explicitly from their submodules. There is an issue with dynamic model attributes like objects and id that Ty doesn’t recognize.

I’m encountering persistent unresolved-attribute errors when running Ty static type checker on Django models, specifically on standard Django model attributes such as id, demo_name, and objects. These errors occur even though the Django model is properly defined, registered, explicitly imported and confirmed to have those attributes in the Django shell.

Steps to reproduce:

Define a Django model with fields such as id, demo_name in apps/sample/models/example.py.

Confirm the model loads and works correctly inside the Django shell:

from apps.sample.models.example import Demo
from django.db import models

issubclass(Demo, models.Model)  # Returns True
Demo._meta.get_fields()  # Returns expected model fields including 'id'
Demo.objects.all()  # Executes without error

Run Ty on a test file that uses this model, e.g. test_ty_model.py:

def test_model_fields(m: Demo):
    reveal_type(m.id)
    reveal_type(m.demo_name)
    reveal_type(m.save)

Ty reports errors like:

error[unresolved-attribute]: Type `Demo` has no attribute `id`
error[unresolved-attribute]: Type `Demo` has no attribute `objects`

I have tried running Ty with explicit environment variables to load Django settings, but the errors persist:

PYTHONPATH=. DJANGO_SETTINGS_MODULE=proj.settings.dev ty check test_ty_model.py

Expected behavior: Ty should recognize standard Django model attributes (id, objects, model fields) and when the Django environment is correctly configured.

Actual behavior: Ty reports unresolved-attribute errors for these standard model attributes, even though Django shell confirms their existence.

Environment:

Ty version: 0.0.1-alpha.18 (d697cc092 2025-08-14) Python version: 3.13.6 Django version: 5.2.5 OS: macOS 15.6 24G84

Project structure:

project-root/
├── manage.py
├── test_ty_model.py             
├── apps/
│   ├── sample/
│   │   ├── models/
│   │   │   └── example.py
├── proj/
│   ├── settings/
│   │   └── base.py
│   │   └──  dev.py

Version

0.0.1-alpha.18 (d697cc092 2025-08-14)

[carljm]

Thanks for the report! At the moment we don't have any dedicated support for Django, and due to Django's use of dynamic metaclass modifications, some attributes of Django's models aren't visible to a type-checker unless it implements dedicated Django support.

I'm a bit confused by the mention of using django = true in .ty.toml, since no such option exists (or has ever existed) in ty; seems like maybe something hallucinated by an LLM?

We would like to add some kind of Django support in future; will keep this issue open to track that.

[MichaReiser]

We also don't support .ty.toml. The configuration file must be named ty.toml and the src option is src.root = ["apps", "proj"]. Python path is under environment, etc. See https://docs.astral.sh/ty/reference/configuration/#environment

[aaschenbrener]

Thank you for the update. Yes, I was having trouble with django and difficulty figuring out how ty.toml could help and attempted to on an LLM to help configure. It seems to have hallucinated a lot. I've removed the ty.toml file completely for now.

[VaishnavGhenge]

+1. Django is one of the most popular Python frameworks, and these unresolved-attribute errors on model fields make ty unusable for Django projects without sprinkling # ty: ignore everywhere. Would love to see either native support for Django's model metaclass patterns or a plugin system for django-stubs integration.

@carljm

[rcampos87]

I have a lot of errors of the type

Attribute id may be missing on object of type Unknown | ForeignKey - accessing id in a FK Attribute save may be missing on object of type Unknown | ForeignKey - accessing save in a FK Element BigIntegerField of this union is not assignable to int - passing pk/id to a function that takes int Attribute hour may be missing on object of type Unknown | DateTimeField - accessing hour of a datetime field No argument provided for required parameter cls of function as_manager - overriding objects manager

[beaugunderson]

it does sound like there's a commitment to future Django support, which I am REALLY looking forward to!