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!
it seems like they've also solved the inline metadata dependencies syncing in scripts finally. so if you declare script dependencies you'll no longer see module not found errors from that
It's cool to see ty support for scripts. That's something I really needed, and I even developed an extension to solve it: https://github.com/karpetrosyan/uv-vscode
[flagged]
This is what’s up! Having worked on several medium sized python projects where linting and type checking were introduced late in the game, having them as a first class feature of the package manager will save so much unnecessary pain.
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.
[flagged]
I fundamentally appreciate the single tool toolchain but ty‘s hesitant support of Django(’s quirks) preempts the advantages for me.
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 ..
[dead]
It seems like it would make more sense for ty to be integrated with ruff than uv.
I imagine uv will subsume both
[flagged]
I can't help it - this sounds not that exciting.
Has the world shifted so much in the last years? I remember when I switched to Linux, many years ago, I worked through LFS (Linux from Scratch) within, say, one or two years. Back then that was kind of exciting; since then I expanded my own scripts for compiling or installing things, including versioned AppDirs, which to me are a lot more logical and elegant too. Why would I need or use uv? Does uv even support versioned AppDirs? How about multiple different glibc on the same system (hint: that works though you have to take care of how things are setup; think of an extended NixOS-like system, with guarantees).
uv seems to be hyped a lot and I still do not understand why.
You don't sound like a Python developer, that's probably the reason. When I search for "AppDirs", I only find references to what is e.g. XDG_BASE_DIRS on Linux (and others on other platforms)? Which I asuume is not what you mean. Most likely this is something particular to your environment, whatever that is.
In the Python ecosystem, uv is great for "project management" - lock files, project dependency environments ("venv"s) etc (similar to npm for js). In the Python ecosystem it's considered best practice to bundle binary dependencies with Python libraries, and then there'll be a binary distribution for each platform (os, libc).
Am I alone in thinking type hints are largely a waste of time in Python and can be actively harmful?
I had claude run ty via this new "uv check" on a moderately sized Python package (cli+tui to a multi-transport messaging system) and it found 67 things. Claude checked each finding for bugginess and found 1 is marginally worth fixing. A large fraction of the findings were ty guessing the type and being wrong. Hinting would I guess remove those wrong guesses but hinting is a PITA and greatly increases code size, both of which is bad for human and LLM.
Do people really get benefit from going all-in with type hinting?
This feels like rage bait, but yes they do, that’s why it was added to Python after decades of not having it.
Type annotations are generally great, if you've never had the displeasure of working with Python pre type-annotations, you'd know that tracking down "wtf type even is this" was a big part of just working in Python. The extra text/tokens spent on annotations are 100 % worth it, both for humans and LLM.
An issue you run into these days is that even if you have excellent type checking on your own code, some libraries don't. You of course want to avoid such libraries, or see if you can find type stubs. Gradual typing can suck, but well-typed Python is a bliss.
I'm really glad that unlike most other recent acquisitions, OpenAI's acquisition of Astral had seemingly no negative impact on their products
…yet. I’m definitely concerned for the future. Especially because uv is so good. The rug pull is going to hurt a lot.
It’s barely been 6 months. Give it time.
Don't worry, they'll find a way to enshittify the product at one point. uv went from being a VC-funded tool written in another language (i.e., with a limited contributor pool) to being an AI bubble-funded tool, so it's not something I'd trust would be maintained for a long time.
It's MIT licensed. If Astral ever truly dies, there'll be community versions of their software, because it's that "necessary".
One step closer to bringing the Rust experience to Python. Good.
This isn't the Rust experience. Rust still distributes clippy as completely separate from cargo, and rustfmt as separate too, etc. it's technically only rustup that centralizes the distribution of the tools together.
Nevertheless, since rustup is most folks entry point to the rust ecosystem, they are effectively distributed together, and rustfmt is fully integrated in cargo.
what happened to pyx?
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.
Eh I think that’s a pretty uncharitable take.
They did the same thing with ruff too. A totally optional interface through the uv command. Use it or not.
I agree, it sounds like they're trying to expand their moat because they realised they were too late to the better type-checking party.
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.
Can you elaborate on losing the type checker race?
I am tasked with creating a new baseline for python projects. My first hunch was uv, ty, ruff as I've had a good time with them in the past.
What would you recommend?
Pyrefly is better than ty for my use cases. Maybe ty will get there some day.
ty is too permissive when I've tried it. It got better with time, and is maybe even quite ok now, but still, the ideology seems to be to allow anything it doesn't quite understand. Which just doesn't align well with my idea of what a type checker is supposed to do. Pyrefly has much better checks IME (at least with strict mode). On top of that, they have specific support for things like Polars schema checking and array shape checks also (supposedly - haven't tried the latter). Which are just incredible niceties.
The whole python tooling is experiencing kind of a renaissance with new Rust based tools taking over.
These days all my project use uv for project management and ruff for linting and formatting.
I believe there is no obvious default for type checking yet. I use whatever my IDE provides. So e.g. pylance in VSCode, which is build on pyright.
There are currently pretty much 3 projects that I look out for: ty, zuban and pyrefly.
At this point, pyrefly seems to me to be the furthest along with support for many common libraries like pytest, pydantic, django, pandas/polars. And meta actually positions it as a production ready system and not a (pre?)beta. Which is why I decided to test drive it.
I have not directly compared the type checkers, I cannot give you a recommendation. For all I know zuban or ty could be the better choice.
uv and ruff took over because they were in many ways simpler and much faster than the competition. ty does not have that luxury.
To be fair, at least when I tested it on a moderately sized codebase, ty was definitely faster than Pyrefly. Like twice as fast (0.5s vs 1s, give or take). However, it's not really critical to save that half a second for full checks. Both have gradual checking when used as a LSP. And on CI, there is overhead from other things.
However, it remains to be seen to what degree that speed difference is due to ty's smaller feature footprint. It just doesn't seem to check the same things. I found it too permissive, personally.
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...
I don't. Formatting and linting does not belong into a package manager.
That's how Rust's Cargo and Elixir's Mix both work.
For cargo, not quite.
rustfmt is what implements Rust formating. However rustfmt is also distributed via rustup (Rust's toolchain manager). There it is also exposed under the alias cargo-fmt, which makes it work as cargo subcommand `cargo fmt` (a mechanism that's available to any crate). So it's technically not "part of cargo".
Of course the nature of all of this is a bit different, as Rust maintains cargo, rustfmt and a lot more dev tooling as part of it's official teams in comparison to other language ecosystems, where focus is on the compiler only.
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.
Lock in on uv isn't a terrible thing if you consider the abysmal state of Python tooling
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.
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.
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.
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.