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.
This shouldn't be surprising. Astral has wanted to create lock-in with uv for years and obviously they'll want to bring everyone into their "ecosystem" as much as possible. Stand by for more divergences from main python or use of their "market" capture for leverage over it.
Main python should move faster on standardizing fixes to its abysmal package distribution scheme, then. Nobody is trying to replace cargo.
Lock in on uv isn't a terrible thing if you consider the abysmal state of Python tooling
It's not something I really relate to, having working on a fairly large project with significant dependencies that is used as both a library and an application. I see uv often used just to try to paper over bad dependency and compatibility management, which ends up being self-reinforcing. I guess if it's being used strictly for final deployment, sure, but that doesn't (shouldn't) remove the need to pay attention. It's hard for me to see it as anything but an attempt to eventually make the state of Python tooling be "everything breaks, unless you use uv by Astral™"
To what end? Do they make money off of it somehow?
A implies B does not mean B implies A too. You can use ty separately, this isn't stopping that, but it is useful for uv check to use ty together.
> keeping them as standalone tools seems most natural
It's natural to us, purists, but I doubt people care. Everyone wants a single tool that allows them to `uv check` and `uv run` in every project without having to install anything.
You have to install uv. Which isn't even present in many distributions.
Thank god it has opinionated quirks that old timers dislike.
Otherwise we'd still be stuck in the complete dumpster fire that was the python packaging/venv we had for the previous 20 years.
Old timer here: uv is not the first opinionated tool to manage Python packaging. It is build learning from other tools right and wrongs. I now use uv for everything because its quirks are less disruptive than quirks from previous tools that I also tried and disliked for being a bit too much for a very small gain.
What you call "dumpster fire", I call "steps towards uv", maybe even better tools in the future.
The only major opinionated tools that were in use prior to uv were Conda, Pipenv and Poetry (- ignoring pip here, as it's mainly a package installer). None of them contributed towards PEP 518 (Conda significantly predated it, and Pipenv actively created a competing format even though the PEP already was accepted).
Most of the lessons that make uv good can be directly traced back to Cargo (which in turn can be traced back to Bundler). The main portions from the Python side that helped it have a good foundations were standards work (PEPs), none of which were driven by the people behind any of the three "major" package managers.
True, before UV the only way to package python was a container.
Yes. we switched from devcontainers to uv and the workflow is now much simpler and faster.
Poetry?
And pipenv, or just literally manually creating a venv. Uv didn't invent that, it's winning on speed mainly, and then capitalising on starting with a base that includes multiple general improvements in the Python ecosystem.
uv also installs the python version your project needs which is a huge pain in the ass if you use some old Linux distro with outdated python.
Like pyenv pioneered for python and nvm for node ? ;)
Years ago
Sure, but it's not a matter of capability but of low friction and sane defaults.
These things matter though a lot of developers don't seem to understand that.
In a uv project I can just git clone, cd, uv sync and I am ready to go. Nothing in the python ecosystem offered that before.
Yup, I ended up learning docker because Python packaging was such a dumpster fire.
I'll never forget the day I discovered that pip didn't do any dependency resolution. You had one job, and yet...
Until uv, I used docker to run python projects locally. Got so fed up with venvs and versions and slowness and lack of wheels and spending so much time mucking around with it when cloning or updating a repo.
Uv hasn't fixed all issues, but made it far less painful.
apt install …
When people all have these special needs they never show their code.
Projects that use ty for its type checking but something else than uv for managing dependencies are probably in a very tiny minority of users.
but there's probably lots of projects that use uv, but not ty.
I'd imagine that, for a substantial percentage of these, part of it is to avoid negotiating and bargaining over an additional tool in your CI arsenal, especially in bigger corporate environments where these sort of conversations are dragged through layers of non-technical middle management.
Ty isn't a compelling option. If you want support for dynamic libraries, mypy is king. If you want speed and strict conformance, Pyrefly and Zuban are better.
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.