Astral merges uv and ty so Python scripts check themselves
Bringing uv and ty together
Astral has shipped an experimental integration between uv, its package manager, and ty, its type checker. ty now reads PEP 723 inline metadata to discover scripts across a project and calls uv to build an environment for each one, so scripts with different dependencies are each checked against their own requirements, in the editor and on the CLI. A new uv check command syncs dependencies and type-checks in one step, and Ruff support is planned.
uv understands your Python project's environment and dependencies, while ty understands your code. By combining the two, we can unlock new functionality beyond what either tool can provide individually.
- miki123211
I am a Python programmer. I love Astral; I think Ruff is great and uv is life-changing, but I don't actually like ty that much.
I want my type checker to check types and to scream at me when it can't. I don't want it to do "gradual typing", if it is unsure about what type something is, I want that to be a failure instead of it modeling the unsureness and not showing potential errors. We live in the age of agents, having to add an extra annotation here and there is not so much of a problem any more.
Meta's Pyrefly largely does what I want. I don't quite love Pyrefly either; I don't like the fact that it edge-cases and gives monopoly status to some popular packages (Pydantic, Django, attrs) instead of offering generalized mechanisms that less popular packages could also utilize, but purely on a type checking front, it's excellent.
- assumed_throwaw
I love Astral’s tools, but I wonder why the CLI feels so fragmented.
- Now, ty is integrated into uv, while ty is technically being part of ruff [1], but ruff is not integrated into uv.
- The formatter is part of ruff, but uv also have an undocumented "format" command, which does not produce the same results.
- Actually, ruff is integrated into uv, but you must call it through "uv tool run ruff".
I guess I'd like "uv format" and "uv lint" to become the standard commands.
[1] https://github.com/zed-extensions/pyrefly/issues/26#issuecom...
- WhyNotHugo
I dislike the idea of these separate tools being blended like this. ty is currently perfectly usable on non-uv projects. uv has *a lot* of opinionated quirks, its custom lockfile lockfile, and other nuances which many of us dislike — ty being a separate tool works fine with plain pip plus any other dependency manager (e.g.: pip-tools).
Of note though, ty doesn't NEED to be integrated into uv, nor vice-versa; keeping them as standalone tools seems most natural.
- olive-n
I feel like pyrefly was gaining some traction over the year. I started using it this week.
This seems like astral realizing they lost the type checker race and now fold it into their popular project so people have a reason to use it.
If it is already installed with uv, people have less reason to look for a type checker and will just stay with the default option.
- shahbazac
I’m not a fan of ‘uv run …’ and other tools interfering with running scripts or programs. I hope core Python developers are looking to “protect” the main interface for using Python. I don’t necessarily mean this in an adversarial way, but more and more QuickStart and installation pages for software require the use of uv, conda, 20 variations of venv, etc.
There is clearly a gap in tooling. We have had a cambrian explosion of tools and we have tried many options. Now it is time for core Python folks to step in and consolidate the ecosystem.
- bitpush
I really really love uv but this uv-ty post seems "shipping the org chart"?
They could have just said uv now has type chancing capabilities (or whatever it is ..) ty afaik isn't a super popular brand so the post makes people first understand what ty is ..
- thayne
It seems like it would make more sense for ty to be integrated with ruff than uv.
- xavdid
Ah, this is great! It's a step towards solving my biggest complaint with PEP 723 scripts: bad editor support.
I loved the idea on paper, but without manually creating a matching venv & installing my deps, I wouldn't get in-editor completions during development. That was fine for small things, but intolerable as the script grew. So it's still not a feature I've used much, since it made more sense to just make a real dev environment.
I'm glad to see there'll be improvements here!