[conorbergin]

I use a lot of obscure libraries for scientific computing and engineering. If I install it from pacman or manage to get an AUR build working, my life is pretty good. If I have to use a Python library the faff becomes unbearable, make a venv, delete the venv, change python version, use conda, use uv, try and install it globally, change python path, source .venv/bin/activate. This is less true for other languages with local package management, but none of them are as frictionless as C (or Zig which I use mostly). The other issue is .venvs, node_packages and equivalents take up huge amounts of disk and make it a pain to move folders around, and no I will not be using a git repo for every throwaway test.

[auxym]

uv has mostly solved the python issue. IME it's dependency resolution is fast and just works. Packages are hard linked from a global cache, which also greatly reduces storage requirements when you work with multiple projects.

[storystarling]

uv is great for resolution, but it seems like it doesn't really address the build complexity for heavy native dependencies. If you are doing any serious work with torch or local LLMs, you still run into issues where wheels aren't available for your specific cuda/arch combination. That is usually where I lose time, not waiting for the resolver.

[amluto]

uv does nothing to help when you have old, crappy, barely maintained Python packages that don’t work reliably.

[drowsspa]

You still need to compile when those libraries are not pre compiled.

[hbfbdhdjd]

It sounds like your understanding of modern package management is at least ten year out of date, and Python has been (until recently) among the worse, yes, so that definitely wouldn’t have been a model to follow

[megolodan]

compiling an open source C project isn't time consuming?