Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PYX: The next step in Python packaging

astral.sh

Post reply on HN
Print view View original

161–170 of 479 posts

Re: PYX: The next step in Python packaging

#161

Post by woodruffw »

nilamo wrote: post #158
woodruffw wrote: post #114

Earlier quoted context omitted.

It was three years ago; 2018 is when they considered removing the command, not when the search API was actually removed from PyPI. And this is part of the interlocking considerations I mentioned: there are private indices that supply the XML-RPC API, and breaking them doesn't seem justifiable[1]. Edit: fixed the link. [1]: https://github.com/pypa/pip/issues/5216#issuecomment-1235329...

Does that seem like a real solution to you? That it's ok to represent a never-functional operation as one that might maybe work? ...because it could work of you jump through a bunch of undocumented hoops? It's so wild to me that so many people are apparently against making a user-friendly update. The whole thing seems very against pep8 (its surprising, complicated, non-specific, etc)

I don't know what to tell you; I just gave an example of it being functional for a subset of users, who don't deserve to be broken just because it's non-functional on PyPI.

Nobody wants anything to be user-unfriendly. You're taking a very small view into Python packaging and extending it to motives, when resources (not even financial ones) are the primary challenge.

Re: PYX: The next step in Python packaging

#162

Post by jcelerier »

ilvez wrote: post #70
giancarlostoro wrote: post #45

Earlier quoted context omitted.

Stuff like that led me fully away from Ruby (due to Rails), which is a shame, I see videos of people chugging along with Ruby and loving it, and it looks like a fun language, but when the only way I can get a dev environment setup for Rails is using DigitalOcean droplets, I've lost all interest. It would always fail at compiling something for Rails. I would have loved to partake in the Rails hype back in 2012, but ov…

Do I get it right that this issue is within Windows? I've never heard of the issues you describe while working with Linux.. I've seen people struggle with MacOS a bit due to brew different versions of some library or the other, mostly self compiling Ruby.

On Linux good luck if you're not using anything besides the officially nvidia-supported Ubuntu version. Just 24.04 instead of 22.04 has regular random breakages and issues, and running on archlinux is just endless pain.

Re: PYX: The next step in Python packaging

#163

Post by c0balt »

poly2it wrote: post #72
giancarlostoro wrote: post #45

Earlier quoted context omitted.

Stuff like that led me fully away from Ruby (due to Rails), which is a shame, I see videos of people chugging along with Ruby and loving it, and it looks like a fun language, but when the only way I can get a dev environment setup for Rails is using DigitalOcean droplets, I've lost all interest. It would always fail at compiling something for Rails. I would have loved to partake in the Rails hype back in 2012, but ov…

Have you tried Nix? https://nixos.org

Given they mentioned Windows (and not WSL) that might not be a viable option. AFAIK, Windows is not natively supported by nixpkgs.

Re: PYX: The next step in Python packaging

#164

Post by kavaruka »

nodesocket wrote: post #77
fph wrote: post #56

I lost track of how many different ways to install a Python library there are at the moment.

Much better than the Node a handful of years back. Everybody used NPM, everybody switched to Yarn, everybody switched back to NPM.

I think node has a better tooling and ecosystem right now. Astral is doing a great job to reduce the gap.

Re: PYX: The next step in Python packaging

#165

Post by zanie »

scarlehoff wrote: post #134
charliermarsh wrote: post #54

Earlier quoted context omitted.

> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx? We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to automatically install a version of PyTorch based on your machine's GPU from the PyTorch index. pyx takes that idea and pushes it further. Instead of "just" supporting PyTorch, the registr…

Hi Charlie what happens in a situation in which I might have access to a login node, from which I can install packages, but then the computing nodes don't have internet access. Can I define in some hardware.toml the target system and install there even if my local system is different? To be more specific, I'd like to do `uv --dump-system hardware.toml` in the computing node and then in the login node (or my laptop fo…

Yes, we let you override our detection of your hardware. Though we haven't implemented dumping detected information on one platform for use on another, it's definitely feasible, e.g., we're exploring a static metadata format as a part of the wheel variant proposal https://github.com/wheelnext/pep_xxx_wheel_variants/issues/4...

Re: PYX: The next step in Python packaging

#166

Post by cyberax »

actinium226 wrote: post #86
asa400 wrote: post #49

Earlier quoted context omitted.

As someone outside those communities, could you elaborate?

Not the person you're replying to, so I don't know if this is what he had in mind, but with Python packages you can distribute more than just Python. Some packages contain C/C++/Fortran/Rust/others? source code that pip will try to automatically build upon install. Of course you can't expect everyone to have a dev environment set up, so packages can also contain pre-compiled binary for any combination of windows/mac/…

> Some packages contain C/C++/Fortran/Rust/others? source code that pip will try to automatically build upon install.

And in the TS/JS world we have React.Native that has a flexible pluggable model that allows creating XCode projects with autodiscovered dependencies in C, C++, Swift and other languages.

It's also flexible enough to allow third-party products like Sentry to integrate into the build process to upload debug symbols to the Sentry servers on release builds.

So no, Python is really not unique in its requirements.

Re: PYX: The next step in Python packaging

#167

Post by jsmeaton »

zanie wrote: post #23
kinow wrote: post #18

Earlier quoted context omitted.

I haven't adopted uv yet watching to see what will be their move. We recently had to review our use of Anaconda tools due to their changes, then review Qt changes in license. Not looking forward to another license ordeal.

We're hoping that building a commercial service makes it clear that we have a sustainable business model and that our tools (like uv) will remain free and permissively licensed. (I work at Astral)

I've been wondering where the commercial service would come in and this sounds like just the right product that aligns with what you're already doing and serves a real need. Setting up scalable private registries for python is awful.

Re: PYX: The next step in Python packaging

#168

Post by cyberax »

zemo wrote: post #41
woodruffw wrote: post #19

Earlier quoted context omitted.

For what it's worth, I understand this concern. However, I want to emphasize that pyx is intentionally distinct from Astral's tools. From the announcement post: > Beyond the product itself, pyx is also an instantiation of our strategy: our tools remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we'll offer paid, hosted services that represent the "natural next thing you ne…

> Basically, we're hoping to address this concern by building a separate sustainable commercial product rather than monetizing our open source tools. jfrog artifactory suddenly very scared for its safety

They've been the only game in town for a while, and their pricing reflects it. But this project is only for Python (for now?) so JFrog is not _immediately_ in danger.

Re: PYX: The next step in Python packaging

#170

Post by [deleted] »

m_kos wrote: post #40

> Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA? This is so true! On Windows (and WSL) it is also exacerbated by some packages requiring the use of compilers bundled with outdated Visual Studio versions, some of which are only available by manually crafting download paths. I can't wait for a better dev experience.

[deleted]
Post reply on HN