Hacker News Reader

Comment by WhyNotHugo | Hacker News Reader

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.

View on HN

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.

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™"

So what you're saying is, "Python tooling isn't bad because I understand all the quirks"

Maybe? I still don't really fully understand what issues people had with it unless they'd only ever used the system python installation for everything.

I found Python tooling completely ok before uv. I quite liked it when it was rye, the features are good, and they’re better now in uv no question. But ultimately I was getting everything I needed using asdf to install python versions and then python -m venv to create virtual environments. Then I’d activate and just use pip.

The uv workflow is better but if the day comes when it becomes a problem due to astral lock-in or whatever may happen it’s ok (as long as those old tools exist..)

To what end? Do they make money off of it somehow?

Main python should move faster on standardizing fixes to its abysmal package distribution scheme, then. Nobody is trying to replace cargo.

Especially now that OpenAI acquired Astral

uv just turned 3, so "years" feels like a stretch. And I think lock-in is not and has never been a goal of the project. uv generally bends over backwards to conform to Python packaging standards because the people who work on uv also tend to work on those standards. The places where it doesn't (like uv.lock) are because the standards can't express exactly the things uv wants.

(Note: I work on both uv and Python packaging standards.)

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.

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.

>If you want speed and strict conformance, Pyrefly and Zuban are better

Not sure if that's true.

Pyrefly and Zuban are faster. Pyrefly and Zuban use less memory. Pyrefly and Zuban score higher on the type system conformance test.

Use whatever tools you want, but don't kid yourself. There's a reason Google adopted Pyrefly.

Where is your evidence?

I think part of ty's pitch is also that it's very simple to set up. I think only Pyright compares in this regard. I tried Pyrefly once and recall it being a bit more involved to start using.

They're all CLI tools and they all support LSP. The only setup advantage here is Pylance's, by virtue of shipping with VS Code. Other tools take two clicks to enable, plus or minus typing the tool's name into a search bar.

And the article says it won’t be automatically installed, so it’s only there for people that want it.

> 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.

If that's a hassle, imagine how much more of a hassle it is to install uv and ty and ruff.

Once you’ve installed uv, adding ruff and ty is trivial. Installing uv is the only hoop you need to jump.

Is it that big an inconvenience? Even if it were included, most software that’s included with a distro is stale the day it’s released.

Software isn't raw milk

It depends. A lot of popular software is relatively new and is subject to frequent upgrades: the rust ecosystem, uv, and mise to name a few. Even the distro’s own Python, Ruby, and Java runtimes are rarely used for software development.

Do you have any stats on that?

Are they rarely used because most software runs on even older versions?

No, it’s because containers.

Reply on news.ycombinator.com