PYX: The next step in Python packaging

Re:PYX: The next step in Python packaging by nemomarx on Wednesday August 13, 2025 @08:04PM (#44895352)

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

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by ghshephard on Wednesday August 13, 2025 @09:01PM (#44895670)

uv is venv + insanely fast pip. I’ve used it every day for 5+ months and I still stare in amazement every time I use it. It’s probably the most joy I’ve ever gotten out of technology.

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by typpilol on Wednesday August 13, 2025 @10:19PM (#44896088)

Installing packages it the most joy you've ever gotten outta tech?

Not a project you built, or something you're proud of? Installing packages?

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by zzzeek on Wednesday August 13, 2025 @11:03PM (#44896333)

I know it's like everyone's lost their mind right ?

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by imp0cat on Thursday August 14, 2025 @12:49AM (#44896837)

Nope. You just haven't wrestled with python packages for long enough to appreciate the change.

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by zzzeek on Thursday August 14, 2025 @08:53AM (#44899810)

Yup I'm a newb

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by mos_basik on Tuesday August 19, 2025 @12:20AM (#44948224)

(zzzeek wrote sqlalchemy, alembic, mako and probably more)

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by imp0cat on Tuesday August 26, 2025 @02:14AM (#45022869)

Oh, that explains a lot!

He creates the software and leaves it for others to install. No wonder he does not appreciate what uv does. ;)

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by frollogaston on Wednesday August 13, 2025 @10:10PM (#44896037)

pip is the default still

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by pama on Wednesday August 13, 2025 @10:51PM (#44896279)

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++ library than other parts of the stack. Or some require different kernel modules or CUDA driver settings. But I would be happy if there was a standardized way to at least link to the same C++ libraries, hopefully with the same ABI, across different clusters or different OS versions. Python is so far from solved…

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by northzen on Thursday August 14, 2025 @02:08AM (#44897226)

Why don't you use pixi?

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by pama on Thursday August 14, 2025 @10:11AM (#44900614)

Pixi inherited some ot the bad designs from conda, and conda clearly hadnt been close to solving python packaging either and was digging itself into a black hole over time.

[ Parent | on HN ]

Re:PYX: The next step in Python packaging by cgravill on Thursday August 14, 2025 @04:01AM (#44897925)

We do something similar with a mix of C++, Fortran, and CUDA dependencies. Using https://cibuildwheel.pypa.io/en/stable/ and the repair functionality to restrict the manylinux to something sensible seems to have handled the complexity - while we mostly use Debian and Ubuntu the Arch folks seemed OK too.

We want to share the wheels more smoothly though and having been looking at pyx for that. Seems promising.

[ Parent | on HN ]