Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks that’s bit less cryptic than the linked page.

Still don’t get how they are solving what they claim to solve.



I'm guesssing from the UV page [0] its mainly if the speed of pip is a problem for you?

[0] https://docs.astral.sh/uv/


There are a bunch of problems with PyPI. For example, there's no metadata API, you have to actually fetch each wheel file and inspect it to figure out certain things about the packages you're trying to resolve/install.

It would be nice if they contributed improvements upstream, but then they can't capture revenue from doing it. I guess it's better to have an alternative and improved PyPI, than to have no improvements and a sense of pride.

There is a lot of other stuff going on with Pyx, but "uv-native metadata APIs" is the relevant one for this example.


I'm guessing it's the right PyTorch and FlashAttention and TransformerEngine and xformers and all that for the machine you're on without a bunch of ninja-built CUDA capability pain.

They explicitly mention PyTorch in the blog post. That's where the big money in Python is, and that's where PyPI utterly fails.


I spend little time with Python, but I didn’t have any problems using uv. Given how great uv is, I’d like to use pyx, but first it would be good if they could provide a solid argument for using it.


I suspect that, in order to succeed, they will need to build something that is isomorphic to Nix.


Yeah, and uv2nix is already pretty good! I wonder if pyx will be competing with uv2nix.

It's easy to compete with Nix tooling, but pretty hard to compete with the breadth of nixpkgs.


They already built uv, which works extremely well for that




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: