PYX: The next step in Python packaging • Hacker News Board

Re: PYX: The next step in Python packaging

#311

Post by rcleveng » Thu, Aug 14, 2025, 6:06 AM UTC

frollogaston wrote: post #289

rs186 wrote: post #252

Earlier quoted context omitted.

I think pip made some poor design choices very early, but pip stuck around for a long time and people kept using it. Of course things got out of control, then people kept inventing new package management until uv comes along. I don't know enough about Python to understand how people could live with that for so long.

Every big Python repo has a Dockerfile, which is much less common in JS.

honestly until UV I thought this was the only sane way to package a python app, now it's still the only sane way and I'll use uv in the dockerfile which is honestly more complicated than their docs or reason would expect.

Re: PYX: The next step in Python packaging

#312

Post by yxhuvud » Thu, Aug 14, 2025, 6:07 AM UTC

x3n0ph3n3 wrote: post #236

tayo42 wrote: post #212

Earlier quoted context omitted.

You can turn that off and allow global packages again if you want. Or install it with the os package manager or something simmilar

You assume the OS package manager I happen to be using even has packages for some of the libraries I want to use.

Or for that matter, that the ones they do have are compatible with packages that comes from other places. I've seen language libraries be restructured when OS packagers got hold of them. That wasn't pretty.

Re: PYX: The next step in Python packaging

#313

Post by northzen » Thu, Aug 14, 2025, 6:08 AM UTC

pama wrote: post #235

nemomarx wrote: post #187

Earlier quoted context omitted.

from what I hear uv is the "solved" and venv by hand is the old way

These tools together solve a fraction of the problen. The other parts of the problem are interfacing with classic c, c++ libraries and handling different hardware and different OSes. It is not even funny how tricky it is to use the same GPU/CUDA versions but with different CPU architectures and hopefully most people dont need to be exposed to it. Sometimes parts of the stack depends on a different version of a c++ li…

Why don't you use pixi?

Re: PYX: The next step in Python packaging

#314

Post by brabel » Thu, Aug 14, 2025, 6:08 AM UTC

hulitu wrote: post #282

Eduard wrote: post #224

Earlier quoted context omitted.

I started with "sudo apt install python" a long time ago and this installed python2. This was during the decades-long transition from python2 to python3, so half the programs didn't work so I installed python3 via "sudo apt install python3". Of course now I had to switch between python2 and python3 depending on the program I wanted to run, that's why Debian/Ubuntu had "sudo update-alternatives --config python" for ma…

Your comment shows the sad state of software quality those days. Rust is the same, move fast and break things. And lately also Mesa started to suffer from the same disease. You basically need, those days, the same build env like the one on the developer's machine or the build will fail.

O was trying to install Stable Diffusion just yesterday. They use Conda, so I installed it and tried to follow the instructions. First, the yaml file they provided was not valid . Following the commands to install packages explicitly failed because my Rust toolchain was old, so I updated it just for some other Rust dependency to fail to build, it didn’t even compile . Such a shit show.

Re: PYX: The next step in Python packaging

#315

Post by kergonath » Thu, Aug 14, 2025, 6:10 AM UTC

Sweet. Yet another Python packaging silver bullet. I can’t wait to ignore this one while I am waiting for next month’s.

Re: PYX: The next step in Python packaging

#316

Post by sussmannbaka » Thu, Aug 14, 2025, 6:11 AM UTC

It’s the year 21XX. Another HN story about python packaging being solved for good this time hits the front page. I try to use a python app, am impressed by its capability to generate 10 pages of red text and go back to cryosleep.

Re: PYX: The next step in Python packaging

#317

Post by northzen » Thu, Aug 14, 2025, 6:12 AM UTC

IHLayman wrote: post #119

morkalork wrote: post #61

Earlier quoted context omitted.

This was basically the reason to use anaconda back in the day.

Anaconda was a good idea until it would break apt on Ubuntu and make my job that much harder. That became the reason _not_ to use Anaconda in my book. venv made these problems start to disappear, and now uv and Nix have closed the loop for me.

Why don't you use pixi, which has the best from these worlds?

Re: PYX: The next step in Python packaging

#318

Post by BrenBarn » Thu, Aug 14, 2025, 6:15 AM UTC

wtallis wrote: post #310

BrenBarn wrote: post #248

Earlier quoted context omitted.

How does it being private mean it doesn't compete with PyPI?

Its purpose is to serve as a repo for stuff that was never going to go on PyPI, whether or not PYX exists.

Oh, I see, I misunderstood the use of the word "private" there.

Re: PYX: The next step in Python packaging

#319

Post by Imustaskforhelp » Thu, Aug 14, 2025, 6:19 AM UTC

ilvez wrote: post #278

Eduard wrote: post #224

Earlier quoted context omitted.

I started with "sudo apt install python" a long time ago and this installed python2. This was during the decades-long transition from python2 to python3, so half the programs didn't work so I installed python3 via "sudo apt install python3". Of course now I had to switch between python2 and python3 depending on the program I wanted to run, that's why Debian/Ubuntu had "sudo update-alternatives --config python" for ma…

I understand this is meant as caricature, but for doing local development tools like mise or asdf are really something I've never looked back from. For containers it's either versioned Docker image or compile yourself.

i think mise can support uv too as its backend https://mise.jdx.dev/mise-cookbook/python.html#mise-uv

Also I mean I understand mise but I personally just prefer using uv for python and bun for typescript both of which can run any version of python/ (node compliant?)

I still like the project though, but I tried to install elixir using it and it was a mess man.

Re: PYX: The next step in Python packaging

#320

Post by Imustaskforhelp » Thu, Aug 14, 2025, 6:23 AM UTC

runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

Uv truly is great, and I mean they are open source and we can always fork it just as how valkey forked redis

And also if you mean that pyx might be hosted on uv, well I think the discussion can go towards that pyx should be made open source but honestly, I am pretty sure that someone might look at pyx and create a pyx api compliant hosted server or I am still curious as to how pyx works and what it actually truly does.