Of note though, ty doesn't NEED to be integrated into uv, nor vice-versa; keeping them as standalone tools seems most natural.
Ty's original pitch was that it would have strong inference and be useful for gradually typing existing, untyped codebases, but AI made that moot. Adding types to existing code is now trivial.
Otherwise we'd still be stuck in the complete dumpster fire that was the python packaging/venv we had for the previous 20 years.
What you call "dumpster fire", I call "steps towards uv", maybe even better tools in the future.
I'll never forget the day I discovered that pip didn't do any dependency resolution. You had one job, and yet...
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 ..
IMO, part of the problem is that people just don’t know that linters or tools like this exist at all. This is the best type of product marketing where the product gets meaningfully better, while educating the users for free.
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!
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.
It's somewhat ironic that they're only just getting around to it actually. The predecessor to `uv`, `rye`, had integration for `ruff` fairly early on - but Astral have really dragged their heels on putting it into `uv` (presumably because `ruff` had already won) and even now aren't adding support until after `ty` is integrated.