Live data from Hacker News

PYX: The next step in Python packaging

astral.sh

471–479 of 479 posts

Re: PYX: The next step in Python packaging

#471

Earlier quoted context omitted.

> especially for GPU stuff you end up having to link against very specific details of the local architecture. Hrm. This doesn’t sound right to me. Any project should target a particular version of Cuda and then the runtime machine simply needs to have that version available. Right? > a lot of people would like to have packages that use pre-installed dependencies that came with the system Those people are wrong. Every…

You are assuming you are allowed to choose which CUDA runtime you can use.

When can I not? Cuda is just a large handful of shared libraries. It’s not magic.

Re: PYX: The next step in Python packaging

#472
post #415
post #393

Earlier quoted context omitted.

to be honest. ill never use uv. python ecosystem tools should be in python.

This is quite a disappointing self-limitation given the improvements uv brings to the table. You’re missing out on some good stuff.

I don't think so. It'd be best to fix native tools.

Re: PYX: The next step in Python packaging

#474
post #393

Earlier quoted context omitted.

to be honest. ill never use uv. python ecosystem tools should be in python.

This is very close minded. It's best to avoid statements like that. I feel like having a working python environment is not a great requirement to managing your python environment.

My OS has hard dependency on python, so i'll always have working python environment.

Also, i tend to run pip like 4-5 times max (except initial package installations) during whole project lifetime, or not at all if packages are in distro already. Its speed is ok for that. So I'm not sure what "should" i miss.

Re: PYX: The next step in Python packaging

#475

Earlier quoted context omitted.

You are assuming you are allowed to choose which CUDA runtime you can use.

When can I not? Cuda is just a large handful of shared libraries. It’s not magic.

When you need to link into the system-provided CUDA versions and not the ones you bring along.

Re: PYX: The next step in Python packaging

#476
post #239

Earlier quoted context omitted.

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

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

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

Re: PYX: The next step in Python packaging

#477

Earlier quoted context omitted.

> But the dependency I need is built and packaged differently for different operating systems and flavor of GPU, and now my coworkers can't get the project to install on their laptops. This is why containers are great IMO. It's meant to solve the problem of "well it works on my machine"

Yeah but it's also nice not having to rely on a container for stuff to work at all, especially when you're doing development.

While I can dev in a container, I don't enjoy the XP nearly as much due to the current state of tooling re remote debuggers.

I do ship containers as a top level .exe equivalent.

Re: PYX: The next step in Python packaging

#478
post #105

Earlier quoted context omitted.

I'm a fan of Deno's deno run http://uri.of.the/dang.program.ts

smells like piping to bash

Same "easy to run" benefit, but Deno has the advantage that it caches everything and won't mess screw your computer unless you `--allow-write` or whatever.

Re: PYX: The next step in Python packaging

#479

Earlier quoted context omitted.

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

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

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. ;)

Post reply on HN