Rendered at 19:14:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
WhyNotHugo 2 days ago [-]
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.
duskdozer 1 days ago [-]
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.
nextaccountic 1 days ago [-]
Lock in on uv isn't a terrible thing if you consider the abysmal state of Python tooling
duskdozer 1 days ago [-]
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™"
smellf 17 hours ago [-]
So what you're saying is, "Python tooling isn't bad because I understand all the quirks"
f17428d27584 1 days ago [-]
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..)
Routine8502 1 days ago [-]
Main python should move faster on standardizing fixes to its abysmal package distribution scheme, then. Nobody is trying to replace cargo.
woodruffw 20 hours ago [-]
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.)
Geezus_42 1 days ago [-]
To what end? Do they make money off of it somehow?
StarlaAtNight 1 days ago [-]
Especially now that OpenAI acquired Astral
satvikpendem 2 days ago [-]
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.
2 days ago [-]
vovavili 2 days ago [-]
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.
jgalt212 2 days ago [-]
but there's probably lots of projects that use uv, but not ty.
vovavili 2 days ago [-]
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.
FreakLegion 1 days ago [-]
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.
npc99 6 hours ago [-]
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.
vovavili 20 hours ago [-]
>If you want speed and strict conformance, Pyrefly and Zuban are better
Not sure if that's true.
FreakLegion 14 hours ago [-]
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.
scott_w 21 hours ago [-]
And the article says it won’t be automatically installed, so it’s only there for people that want it.
photios 1 days ago [-]
> 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.
LtWorf 1 days ago [-]
You have to install uv. Which isn't even present in many distributions.
mpyne 1 days ago [-]
If that's a hassle, imagine how much more of a hassle it is to install uv and ty and ruff.
scott_w 21 hours ago [-]
Once you’ve installed uv, adding ruff and ty is trivial. Installing uv is the only hoop you need to jump.
otterley 1 days ago [-]
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.
LtWorf 22 hours ago [-]
Software isn't raw milk
otterley 21 hours ago [-]
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.
LtWorf 9 hours ago [-]
Do you have any stats on that?
Are they rarely used because most software runs on even older versions?
hmartin 2 days ago [-]
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.
otherme123 2 days ago [-]
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.
hobofan 1 days ago [-]
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.
wiseowise 1 days ago [-]
> uv is not the first opinionated tool to manage Python packaging
It is the first one that "just works".
1 days ago [-]
rcleveng 2 days ago [-]
True, before UV the only way to package python was a container.
veber-alex 1 days ago [-]
Yes. we switched from devcontainers to uv and the workflow is now much simpler and faster.
disgruntledphd2 2 days ago [-]
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...
matsemann 1 days ago [-]
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.
LtWorf 1 days ago [-]
apt install …
When people all have these special needs they never show their code.
disgruntledphd2 1 days ago [-]
So apt install worked if you had a decent Linux box and the correct versions of C and Fortran libraries were available.
I worked with data, so tended to use conda and still have loads of problems. Pre compiled wheels and uv have made the situation a lot better.
LtWorf 9 hours ago [-]
When you do apt install, the maintainer made sure that the correct versions of whatever dependency was indeed available. That's the entire point of a distribution.
bmitc 1 days ago [-]
Poetry?
bheztio 1 days ago [-]
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.
veber-alex 1 days ago [-]
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.
zaphirplane 1 days ago [-]
Like pyenv pioneered for python and nvm for node ? ;)
Years ago
veber-alex 1 days 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.
hobofan 1 days ago [-]
> uv sync
You can also just do "uv run", and it will automatically sync as necessary!
I think that's one of the things that uv does great and often goes unnoticed: It's hard to use wrong for a layman. Forgetting to run the equivalent sync command in most other Python package mangers could have resulted in a myriad of different bugs caused by out of sync packages, leading to hours of wasted debugging.
1 days ago [-]
bmitc 1 days ago [-]
> 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.
`poetry install` does the same thing except for downloading Python.
I transitioned from Poetry to uv. Other than being mildly faster and providing workspaces, uv doesn't really change at all how one interacts with and manages a project. And in fact, uv just adds additional quirks and gotchas and limitations, including storing authorization keys in plain text.
uv also duplicated things in the Python ecosystem but then didn't implement the same feature sets, so you often end up needing to call the existing tool, just like you did in Poetry.
zelphirkalt 23 hours ago [-]
I suspect, that lots of people hyping uv didn't have any proper reproducible project setups beforehand and didn't have to find solutions to that before uv. If they had, they would know about Poetry and how to use it.
I am of the same opinion, that uv didn't actually change all that much, if you have a sane project setup. I don't do anything with it, that I didn't do before with Poetry and before that with Pipenv. What I need is a way of installing dependencies, checked against a lock file, reliably. Poetry does that. If uv disappeared today, I would go back to Poetry and wouldn't miss all that much.
But there are the people who want to write one-off scripts with loosely defined dependencies inlined into the scripts. I don't do that. I would just copy my Makefile and pyproject.toml file from another project and adjust it and then run the script just as well with locked dependencies. Why do anything less. If I want to be really sloppy, I can just pip install.
bigfudge 21 hours ago [-]
I tried really hard to do things the right way before uv, but it was just a major PITA. Poetry in particular looked really exciting when I first discovered it, but I eventually just got bogged down with the speed and its inability to resolve dependencies even for recent versions of pretty mainstream packages. It didn't 'just work' once you got beyond toy projects.
I admit I hadn't really realised astral was a private company before though. What is their roadmap for monetising all this work?
zelphirkalt 21 hours ago [-]
Hm, that's strange. I have used Pipenv and Poetry years ago, to reproducibly build data science environments that people used to learn about data science and data analysis. I don't think you can call that "toy projects". I guess you just had bad luck with some specific dependencies. What I do remember though is, that Poetry had far fewer problems than Pipenv had. Pipenv was still a fight, though I won every time one way or another.
bmitc 21 hours ago [-]
Yea, it's interesting. My comment is negative in votes, but I went back to it to see. Everything I said is factual, so I don't know. People are endlessly impressed by uv's whizbang speed, it seems. In reality, it's _yet another tool_ trying to reinvent the Python ecosystem.
assumed_throwaw 1 days ago [-]
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.
> I guess I'd like "uv format" and "uv lint" to become the standard commands.
Note that `uv format` does exist (in an experimental state) and does what you expect w/r/t invoking Ruff. And `uv check` is the equivalent for ty.
(ty is "part of" Ruff in the sense that it shares a lot of the same machinery, so the two are closely joined in terms of source trees. But it's an entirely separate binary from Ruff's.)
7bit 1 days ago [-]
I don't. Formatting and linting does not belong into a package manager.
f17428d27584 1 days ago [-]
uv manages the entire project. It is not just a different pip.
skribanto 20 hours ago [-]
The use case in the article though is type checking standalone scripts with declared dependencies. So it kind of needs some kind of package management + type checking utility at the same time.
bmitc 1 days ago [-]
That's how Rust's Cargo and Elixir's Mix both work.
hobofan 1 days ago [-]
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.
bmitc 1 days ago [-]
From a user's point of view and an operational standpoint, that is how they work. Mix is the same way in terms of calling tools as subcommands. But it doesn't matter. You get a default experience with `cargo` and `mix` driving everything.
jojva 1 days ago [-]
Why not?
froh 1 days ago [-]
because a package manager manages packages, while a formatter formats source code and a type checker checks types.
the type check is background process for lsp and a quality gate in your process.
formatting likewise with a stronger Fokus on pre-commit
packaging (and build for packaging) may or may not be gated with the former two but it's a (pre)release and deployment activity.
rented_mule 18 hours ago [-]
The very first line of https://docs.astral.sh/uv/ states that uv is more than a package manager: "An extremely fast Python package and project manager, written in Rust."
npc99 6 hours ago [-]
what is a "project manager" in this context?
I think it's safe to say most of us who use `uv` use it as a package manager.
upstream has created hatchling for the other part of uv indeed
miki123211 1 days ago [-]
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.
remus 1 days ago [-]
> 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.
A good goal, but a hard sell for a tool when the underlying typing spec is very flexible and designed to allow for gradual typing. And of course there are all sorts of python codebases with everything from no types to very tightly specified types.
hedgehog 1 days ago [-]
Have you tried Zuban? The last time I looked at the options I preferred it for similar reasons to why you like Pyrefly, though I haven't re-evaluated recently.
zelphirkalt 23 hours ago [-]
Zuban is a one-man show though, with a bus factor of probably 1.
miki123211 4 hours ago [-]
And it's also AGPL, which is a legal gray area and a headache in many places, even those that technically aren't violating the AGPL.
Vaslo 20 hours ago [-]
I tend to do all my own uv stuff but let AI handle ty for me. I don’t have many issues that way.
olive-n 2 days ago [-]
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.
chippiewill 1 days ago [-]
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.
icecatUnraveled 1 days ago [-]
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?
olive-n 1 days ago [-]
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.
bheztio 1 days ago [-]
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.
jessekv 1 days ago [-]
Pyrefly is better than ty for my use cases. Maybe ty will get there some day.
bheztio 1 days ago [-]
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.
Kinrany 1 days ago [-]
It's a good default for a pre-1.0 tool that aims to type check existing code.
calderwoodra 19 hours ago [-]
Coincidentally, we also went to pyrefly in the last month or so.
With AI able to quickly solve the adoption and migration, it just became a matter of picking the best tool - pyrefly has everything and is faster than ty.
JoshCLWren 1 days ago [-]
I think with google choosing to go with pyrefly a couple weeks ago it seems to signal that ty ain't it.
jsmeaton 1 days ago [-]
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.
shahbazac 1 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
It seems like it would make more sense for ty to be integrated with ruff than uv.
NegativeLatency 2 days ago [-]
I imagine uv will subsume both
hujun236 1 days ago [-]
[flagged]
xavdid 2 days ago [-]
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!
zahlman 1 days ago [-]
> That was fine for small things, but intolerable as the script grew.
...Just how much do your single-file scripts grow that this becomes a problem?
xavdid 1 days ago [-]
It depends! It's more about growing complexity than LoC. Like if I'm pulling more and more functionality out of cyclopts[0] for arg parsing. Each time I have to go to the docs instead of getting in-editor suggestions it's a little bit more annoying. The earlier I swap over, the nicer it is.
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.
what 21 hours ago [-]
Unhinged. Linting and type checking are not concerns of a package manager.
nehalem 2 days ago [-]
I fundamentally appreciate the single tool toolchain but ty‘s hesitant support of Django(’s quirks) preempts the advantages for me.
I just removed ty from our codebases at work in favor of Pyrefly which is everything I wanted from ty. We're gradually going to a strict-typed python and Ruff and UV are incredible but ty has been a disappointment. In my personal projects I've replaced ty with mypy as an experiment to see how much it improves agentic coding. I bought into the idea of ty being eventually good enough but in the last year or so it hasn't happened.
benhurmarcel 37 minutes ago [-]
How does pyrefly compare to mypy then?
flexagoon 2 days ago [-]
I'm really glad that unlike most other recent acquisitions, OpenAI's acquisition of Astral had seemingly no negative impact on their products
doot 2 days ago [-]
It’s barely been 6 months. Give it time.
2 days ago [-]
Kwpolska 1 days ago [-]
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.
bheztio 1 days ago [-]
It's MIT licensed. If Astral ever truly dies, there'll be community versions of their software, because it's that "necessary".
Kwpolska 1 days ago [-]
The community of people fluent in Rust who care about Python packaging and who are not Astral employees is tiny.
woodruffw 20 hours ago [-]
PyO3 is an extraordinarily popular project, and there are (tens of?) thousands of Python packages using it. I think we're years past the point of the Rust/Python intersection being small.
yoyohello13 2 days ago [-]
…yet. I’m definitely concerned for the future. Especially because uv is so good. The rug pull is going to hurt a lot.
Philpax 2 days ago [-]
One step closer to bringing the Rust experience to Python. Good.
LoganDark 2 days ago [-]
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.
swiftcoder 1 days ago [-]
Nevertheless, since rustup is most folks entry point to the rust ecosystem, they are effectively distributed together, and rustfmt is fully integrated in cargo.
LoganDark 21 hours ago [-]
cargo-fmt is not part of Cargo, it's distributed with rustfmt and uses the same mechanism as third-party subcommands like cargo-expand. Neither are cargo-clippy and cargo-miri.
(Cargo does, however, contain a small list of those official subcommands so that if you try to use one that's missing, it can remind you to install the corresponding component.)
grandimam 24 hours ago [-]
This feels more like we are moving towards a Bun-like model where tooling becomes a unified runtime experience, handling everything from dependency management, package, linting, type checking and finally execution. To me, merging uv, ruff, and ty seems like a natural organizational step.
MaxMonteil 1 days ago [-]
Maybe this is somewhat inspired by the consolidation happening in JS land with Vite Plus and Void 0.
Vite+ is making it easier to use their linting, formatting (, and more) together though they can still operate fully independently.
having a language be reliant on external typing for even the most popular libraries feels so passè and backwards even though it's clearly the way things are evolving with typescript and python
kaangiray26 1 days ago [-]
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
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.
bheztio 1 days ago [-]
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).
smnc 1 days ago [-]
They are probably referencing the AppImage-related AppDirs.
> AppDirs are the “source” of AppImages. When building an AppImage, a file system image is built from such a directory, to which a runtime is prepended.
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?
mindwok 1 days ago [-]
This feels like rage bait, but yes they do, that’s why it was added to Python after decades of not having it.
paskejl 1 days ago [-]
I work mostly with Python and I cannot image my life without type hints.
If you ever had to maintain anything in prod, they're a must.
I would understand the view of some people thinking "why even use python then" but that's a whole other conversation.
bheztio 1 days ago [-]
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.
zahlman 1 days ago [-]
I work with Python today without type annotations, don't find that kind of type tracking difficult at all, nor do I find the annotations worth the effort. The questions I've seen over the years, meanwhile, from people trying to force the annotation system to do strange things, have suggested to me that people are creating far too much complexity for themselves. Incidentally, IMX, ChatGPT usually writes un-annotated new code unless you specifically ask for annotations. And it can easily refactor that un-annotated code, too.
Annotations are ignored by the compiler (except insofar as they require adding some attributes to objects) and do not guide the bytecode-compilation process or empower any kind of optimization (without a dedicated third-party system like mypyc). Nor are they relevant to PyPy. They are not even free abstractions: as mentioned some objects gain additional attributes (in case you want to introspect something at runtime, but you usually don't), and e.g. calls to `typing.cast` still have to be looked up and made even though it's explicitly intended as a no-op. Plus, expecting annotations to reflect types that can be statically checked gets in the way of other interesting uses of annotations (and the original PEP explicitly designed with other use cases in mind).
I have been using Python for over 20 years. If anything, my attitude has become further against type annotations in the last few.
skribanto 19 hours ago [-]
I routinely run into issues, where Claude will try to add functionality to a dict-heavy API and messup the keys, I just do an initial pass converting everything to dataclasses, and it can iterate on it's own with the typechecker to fix everything on it's own, but otherwise I have to do a bunch of manual iterations.
zahlman 13 hours ago [-]
If it works for you, great. I'd just suggest trying `TypedDict` first; that's probably less disruptive.
rr808 1 days ago [-]
The other great thing about type annotations is that you dont have to use them. Coming from strongly typed language background its life changing for me to sometimes rely on them sometimes just ignore.
Of note though, ty doesn't NEED to be integrated into uv, nor vice-versa; keeping them as standalone tools seems most natural.
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..)
(Note: I work on both uv and Python packaging standards.)
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.
Not sure if that's true.
Use whatever tools you want, but don't kid yourself. There's a reason Google adopted Pyrefly.
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.
Are they rarely used because most software runs on even older versions?
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.
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.
It is the first one that "just works".
I'll never forget the day I discovered that pip didn't do any dependency resolution. You had one job, and yet...
Uv hasn't fixed all issues, but made it far less painful.
When people all have these special needs they never show their code.
I worked with data, so tended to use conda and still have loads of problems. Pre compiled wheels and uv have made the situation a lot better.
Years ago
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.
You can also just do "uv run", and it will automatically sync as necessary!
I think that's one of the things that uv does great and often goes unnoticed: It's hard to use wrong for a layman. Forgetting to run the equivalent sync command in most other Python package mangers could have resulted in a myriad of different bugs caused by out of sync packages, leading to hours of wasted debugging.
`poetry install` does the same thing except for downloading Python.
I transitioned from Poetry to uv. Other than being mildly faster and providing workspaces, uv doesn't really change at all how one interacts with and manages a project. And in fact, uv just adds additional quirks and gotchas and limitations, including storing authorization keys in plain text.
uv also duplicated things in the Python ecosystem but then didn't implement the same feature sets, so you often end up needing to call the existing tool, just like you did in Poetry.
I am of the same opinion, that uv didn't actually change all that much, if you have a sane project setup. I don't do anything with it, that I didn't do before with Poetry and before that with Pipenv. What I need is a way of installing dependencies, checked against a lock file, reliably. Poetry does that. If uv disappeared today, I would go back to Poetry and wouldn't miss all that much.
But there are the people who want to write one-off scripts with loosely defined dependencies inlined into the scripts. I don't do that. I would just copy my Makefile and pyproject.toml file from another project and adjust it and then run the script just as well with locked dependencies. Why do anything less. If I want to be really sloppy, I can just pip install.
I admit I hadn't really realised astral was a private company before though. What is their roadmap for monetising all this work?
- 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...
Note that `uv format` does exist (in an experimental state) and does what you expect w/r/t invoking Ruff. And `uv check` is the equivalent for ty.
(ty is "part of" Ruff in the sense that it shares a lot of the same machinery, so the two are closely joined in terms of source trees. But it's an entirely separate binary from Ruff's.)
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.
the type check is background process for lsp and a quality gate in your process.
formatting likewise with a stronger Fokus on pre-commit
packaging (and build for packaging) may or may not be gated with the former two but it's a (pre)release and deployment activity.
I think it's safe to say most of us who use `uv` use it as a package manager.
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.
A good goal, but a hard sell for a tool when the underlying typing spec is very flexible and designed to allow for gradual typing. And of course there are all sorts of python codebases with everything from no types to very tightly specified types.
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.
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?
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.
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.
With AI able to quickly solve the adoption and migration, it just became a matter of picking the best tool - pyrefly has everything and is faster than ty.
They did the same thing with ruff too. A totally optional interface through the uv command. Use it or not.
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.
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 ..
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!
...Just how much do your single-file scripts grow that this becomes a problem?
[0]: https://cyclopts.readthedocs.io/en/stable/
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.
https://github.com/mr-fatalyst/oxyde
(Cargo does, however, contain a small list of those official subcommands so that if you try to use one that's missing, it can remind you to install the corresponding component.)
Vite+ is making it easier to use their linting, formatting (, and more) together though they can still operate fully independently.
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.
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).
> AppDirs are the “source” of AppImages. When building an AppImage, a file system image is built from such a directory, to which a runtime is prepended.
https://docs.appimage.org/reference/appdir.html
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?
If you ever had to maintain anything in prod, they're a must.
I would understand the view of some people thinking "why even use python then" but that's a whole other conversation.
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.
Annotations are ignored by the compiler (except insofar as they require adding some attributes to objects) and do not guide the bytecode-compilation process or empower any kind of optimization (without a dedicated third-party system like mypyc). Nor are they relevant to PyPy. They are not even free abstractions: as mentioned some objects gain additional attributes (in case you want to introspect something at runtime, but you usually don't), and e.g. calls to `typing.cast` still have to be looked up and made even though it's explicitly intended as a no-op. Plus, expecting annotations to reflect types that can be statically checked gets in the way of other interesting uses of annotations (and the original PEP explicitly designed with other use cases in mind).
I have been using Python for over 20 years. If anything, my attitude has become further against type annotations in the last few.