beeware / beeware/briefcase

Tracking: gradual introduction of ty type checking

Open
#2,709 2 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
3.3k
Forks
549
Avg merge
1d 4h
Merged PRs (30d)
40

Description

### What is the problem or limitation you are having?

There is no type checking in the project. Type errors are caught only at runtime or during review. Previous discussion (#665) concluded that mypy was too slow and annotations weren't an inherent good. [ty](https://github.com/astral-sh/ty) changes the equation — it checks all of `src/briefcase/` in ~0.16s.

See [Type checking with ty (discussion)](https://github.com/beeware/briefcase/discussions/2707) for background.

### Describe the solution you'd like

Gradually introduce ty type checking, module by module, without disrupting existing workflows.

Current state:
- 597 diagnostics on `src/briefcase/` with ty 0.0.18
- Many are `unresolved-attribute` from dynamic attribute access on `BaseConfig`/`AppConfig`
- ~60% of files already have `from __future__ import annotations`
- Newer code (channels, integrations, debuggers) already uses Protocols and annotations

Roadmap:
- [x] #2710 (`tox` env + `pyproject.toml` config, pinned version)
- [x] #2734
- [x] #2739
- [x] #2800
- [ ] Review remaining 192 non-attribute diagnostics for real catches
- [ ] Identify first module(s) to enforce (e.g. `channels/`, `integrations/base.py`)
- [ ] Expand enforcement module by module

### Describe alternatives you've considered

- **mypy**: too slow for pre-commit/CI integration, heavier configuration burden
- **pyright**: faster than mypy but still heavier than ty; not part of the existing Astral toolchain
- **Do nothing**: viable, but misses real catches (e.g. functions with implicit `None` returns typed as `-> bool`)

### Additional context

Principles agreed on in the discussion:
- ty adapts to the codebase, not the other way around
- Non-blocking until a module is explicitly opted in
- Pin ty version, upgrade deliberately
- Dynamic attributes are intentional. Platform modules may stay excluded or warn-only long-term

Contributor guide

Open the contributing guide

Research direction

Read the ty discussion and the existing tox/pyproject configuration from #2710, then inspect the remaining diagnostics under src/briefcase/. Review the 192 non-attribute diagnostics and candidate modules such as channels/ and integrations/base.py; progress is complete when a module is deliberately enforced without disrupting existing workflows.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.