4 ms·

> The only reason they wouldn't connect up - that I can think of, anyway - is because their own Python wrappers currently don't hard-code the right relative pat

> The only reason they wouldn't connect up - that I can think of, anyway - is because their own Python wrappers currently don't hard-code the right relative path It's not just that, it's that you can't specify them as dependencies in a coordinated way as you can with Python libs. You can dump a DLL somewhere but if it's the wrong version for some other library, it will break, and there's no way for packages to tell each other what versions of those shared libraries they need. With conda you can directly specify the version constraints on non-Python packages. Now, yeah, they still need to be built in a consistent manner to work, but that's what conda-forge handles.

zahlman 2y ago
Ah, right, I forgot about those issues (I'm thankful I don't write that sort of code myself - I can't say I ever enjoyed C even if I used to use it regularly many years ago). I guess PEP 725 is meant to address this sort of thing, too (as well as build-time requirements like compilers)... ? I guess one possible workaround is to automate making a wheel for each version of the compiled library, and have the wheel version move in lockstep. Then you just specify the exact wheel versions in your dependencies, and infer the paths according to the wheel package names... it certainly doesn't sound pleasant, though. And, C being what it is, I'm sure that still overlooks something.