Well, for OpenBLAS it seems we’re talking about a C library that exposes a relatively simple (but slightly plethoric) stateless C API. It should be doable to automate the wrapping of those APIs in a PyCapsule and distribute it as a standalone Python extension module.
But, if this is important to you, you can also use conda-forge or Anaconda, since it’s a problem that the conda ecosystem has solved more than 10 years ago.
But, if this is important to you, you can also use conda-forge or Anaconda
Clear, it is a solved problem there. The problem is that other constraints make it interesting to rely on the uv workflow.
It should be doable to automate the wrapping of those APIs in a PyCapsule and distribute it as a standalone Python extension module.
That would be a nice starting point, but only part of the solution. Can the scypy-openblas64 wheel be used for that? The second part is knowing how to build “special” scipy, numpy, cvxopt, and scs wheels with no embedded Openblas and using that module.
All of engineering is about trading off constraints. uv has opted to be based around PyPI, which inherently requires independent redistribution of native dependencies, due to how the ecosystem is designed (which is why Conda packages are not directly compatible, since they had to be fundamentally different to solve the limitation).
If you balance your constraints in a way that leads you to uv, then you just have to deal with the limitations of that choice, just as you’d have to deal with other limitations if you went to conda.
Yes, sharing native dependencies is a fundamental change to how PyPI packages work, which means they all need to coordinate on how to do it. The existing mechanisms either don’t work reliably or have already been traded off (e.g. things like pkg-config), and so there needs to be a significant amount of work to make it viable with a new mechanism. This requires demand, design, and motivation, which is what this thread has been about (though the fact that it fizzled out suggests the motivation isn’t that strong…).
Clear, it is a solved problem there. The problem is that other constraints make it interesting to rely on the uv workflow
FYI if conda packages are a requirement for you then pixi offers similar features to uv and integrates conda packages.
I’ll look into that, thanks!
The existing mechanisms either don’t work reliably or have already been traded off
Thought it was closer to be a problem with a solution… e.g. in pyqt5-qt aren’t only the libraries shipped? And scipy-openblas64 doesn’t contain only the blas libraries? Can’t another package refer to it?