Is ty ready to use in production CI pipelines?

August 29, 2026 5 answers
Asked by MellowCedar42
If you were setting up CI for a project, department, or company today, would you feel comfortable using Astral's ty as the primary Python type checker, or would you choose basedpyright, Pyright, mypy, Pyrefly, or another alternative? I'm configuring CI for a project and currently leaning toward basedpyright because I've used it for a while. ty has been improving quickly, but as far as I can tell, it still isn't fully on par with the more established checkers. How are people evaluating its stability, feature coverage, and diagnostic churn in real-world CI?

Answers

BriskWalrus31
The answer depends on the framework and code style. Zuban is another Rust-based option that some people find more mature for general Python, while mypy remains a strong choice for Django because its Django support is still better. Whichever tool you choose, pin the exact version and treat checker upgrades like any other dependency change.
Reply to this answer
SilverOrbit29
For a conservative production setup, basedpyright or Pyrefly seems like the safer choice right now. ty is improving quickly, but it isn't feature-complete and hasn't accumulated the same amount of ecosystem experience as the established alternatives. I'd evaluate it alongside your current checker rather than make it the only gate immediately.

AmberTrellis84: I moved one project from ty to Pyrefly to compare them. It may be worth trying both on your own code, since support and false-positive behavior can vary a lot by project.

Reply to this answer
PlainComet56
Some teams are already using ty successfully in CI because it has a relatively low maintenance burden and its editor diagnostics line up well with the CI output. I wouldn't dismiss it outright, but I'd only adopt it after testing it against the project's real code and deciding how much diagnostic churn the team is willing to handle.
Reply to this answer
VividMaple63
ty is no longer alpha-quality in the sense of constantly crashing or producing wildly unusable results. It has become fairly dependable and can have a similar balance of false positives and false negatives to mature tools. The main concern is still pre-1.0 API and diagnostic instability, so pin the version and expect some maintenance when upgrading.

NorthwindPanda5: I use it in CI and haven't had serious problems. The results are predictable enough for our codebase, but we pin versions and run a full pipeline whenever the checker is upgraded.

Reply to this answer
QuietHarbor7
I'd stick with basedpyright for now, especially if you're already comfortable with it. ty is still on a 0.0.x version and its maintainers warn that diagnostics and other behavior can change between releases. That kind of churn can be inconvenient in a production pipeline, even if the checker itself is reliable.

CopperLynx18: That matches my experience. The recent problems haven't been crashes so much as reports changing whenever a new edge case is covered or an error is renamed.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions