🔧 Enable ty for type checking

[denialhaag]

Description

This PR experimentally enables ty for type checking.

Checklist:

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Added type checking validation tool to the development and CI pipeline
  • Updated pre-commit hooks and workflow configurations to enable enhanced type checking during development and continuous integration

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Walkthrough

Enabled Astral's ty type-checking tool in the CI pipeline by adding the enable-ty flag to the Python linter workflow, introducing a ty-check pre-commit hook, and adding ty as a dev dependency with configuration settings in the project.

Changes

Cohort / File(s)	Summary
CI Workflow .github/workflows/ci.yml	Added enable-ty: true to the reusable-python-linter workflow invocation in two locations, enabling the ty type checker in the linter job.
Pre-commit Configuration .pre-commit-config.yaml	Added ty-check to the ci.skip list; introduced a new local pre-commit hook ty-check that runs uv sync and uv run ty check for Python and Jupyter files with serial execution.
Project Configuration pyproject.toml	Added ty==0.0.1a29 to the dev dependency group and configured [tool.ty.terminal] with error-on-warning = true to treat warnings as errors.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5-10 minutes

• Changes are straightforward configuration additions across three files with no complex logic or behavioral modifications.
• All alterations follow a consistent pattern: enabling and configuring the ty tool in multiple places.

Possibly related PRs

• 🚨 Enable Astral's type checker ty core#1333: Identical changes enabling Astral's ty in CI workflow, pre-commit, and project configuration.
• 🔧 Enable ty for type checking qcec#775: Parallel implementation adding the same enable-ty flag, ty-check hook, and tool configuration.
• 🐍🚨 Modernize and fix Python linter workflow workflows#254: Modifies the reusable Python linter workflow to support ty integration and dependency installation.

Poem

🐰 A rabbit hops through types so clear,
With ty now checking far and near,
Warnings become errors—none shall pass,
Pre-commit hooks guard the code en masse! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description is minimal but directly addresses the purpose. However, several checklist items are marked with strikethrough, indicating incomplete sections like tests, documentation, and changelog entries.	Consider clarifying whether the experimental nature of this PR justifies skipping tests, documentation, and changelog updates, or if these should be completed before merging.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: enabling the ty type checker tool across the project configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch enable-ty

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fed59b4 and 07d45ef.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• .github/workflows/ci.yml (1 hunks)
• .pre-commit-config.yaml (2 hunks)
• pyproject.toml (2 hunks)

🧰 Additional context used

🧠 Learnings (3)

📓 Common learnings

Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1337
File: pyproject.toml:351-351
Timestamp: 2025-11-28T14:33:15.199Z
Learning: In the munich-quantum-toolkit/core repository, the dev dependency "ty==0.0.1a27" is intentionally pinned to an exact pre-release version. This dependency is used by the `ty-check` pre-commit hook (via `uv run --only-dev ty check`), and the exact pin ensures all developers run the same version, preventing unexpected issues from updates since ty is in alpha and changing rapidly.

📚 Learning: 2025-11-28T14:33:15.199Z

Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1337
File: pyproject.toml:351-351
Timestamp: 2025-11-28T14:33:15.199Z
Learning: In the munich-quantum-toolkit/core repository, the dev dependency "ty==0.0.1a27" is intentionally pinned to an exact pre-release version. This dependency is used by the `ty-check` pre-commit hook (via `uv run --only-dev ty check`), and the exact pin ensures all developers run the same version, preventing unexpected issues from updates since ty is in alpha and changing rapidly.

Applied to files:

• pyproject.toml
• .pre-commit-config.yaml
• .github/workflows/ci.yml

📚 Learning: 2025-10-11T13:21:15.212Z

Learnt from: denialhaag
Repo: munich-quantum-toolkit/ddsim PR: 674
File: .github/workflows/cd.yml:56-56
Timestamp: 2025-10-11T13:21:15.212Z
Learning: In the ddsim repository, modifying .github/workflows/cd.yml intentionally triggers CD workflow testing in CI through a change-detection mechanism in ci.yml. The change-detection job outputs a run-cd flag that controls whether build-sdist and build-wheel jobs execute in CI, allowing testing of the CD workflow (including wheel building and testing) before actual releases.

Applied to files:

• .github/workflows/ci.yml

🔇 Additional comments (4)

pyproject.toml (1)

68-71: Configuration aligns with strict type checking.

The [tool.ty.terminal] configuration with error-on-warning = true correctly enforces strict typing by treating warnings as errors. This is consistent with the strict mypy configuration already in place.

.pre-commit-config.yaml (2)

14-14: Appropriate addition to CI skip list.

Adding ty-check to the pre-commit CI skip list aligns with the pattern used for mypy. Type-checking hooks should skip in CI and run via the dedicated workflow instead, preventing interference with other hooks.

---

75-84: Verify hook implementation against the established pattern.

The ty-check hook implementation uses uv sync --no-install-project --inexact followed by uv run --no-sync ty check. However, retrieved learnings from munich-quantum-toolkit/core PR 1337 show a simpler approach: uv run --only-dev ty check.

Two specific concerns:

1. The --inexact flag is unusual for lock-file-based workflows; typically you want --exact for reproducibility.
2. The manual uv sync before uv run adds complexity that may be unnecessary if uv run --only-dev is sufficient.

Please verify this implementation is correct or consider aligning with the simpler pattern from the related PR.

.github/workflows/ci.yml (1)

43-44: No issues found. The enable-ty: true flag is properly supported by the pinned reusable workflow version (v1.17.3 at commit dbcd4474154dda0794838207274a3bccd4550de0). The reusable-python-linter workflow defines this as a valid boolean input and correctly runs ty check when enabled.