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.
PYX: The next step in Python packaging
471–479 of 479 posts
Re: PYX: The next step in Python packaging
#472Earlier 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.
Re: PYX: The next step in Python packaging
#473Re: PYX: The next step in Python packaging
#474Earlier 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.
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
#475Earlier 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.
Re: PYX: The next step in Python packaging
#476Re: PYX: The next step in Python packaging
#477Earlier 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.
I do ship containers as a top level .exe equivalent.
Re: PYX: The next step in Python packaging
#478Re: PYX: The next step in Python packaging
#479Earlier 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)
He creates the software and leaves it for others to install. No wonder he does not appreciate what uv does. ;)