doc: Document how to deal with dynamic linking #1022
Conversation
Signed-off-by: Cristian Le <[email protected]>
| One downside of these tools is that all dependencies are duplicated and bundled | ||
| in each project. |
There was a problem hiding this comment.
These tools also do name mangling, which ensures that each wheel is independent, as required to be a valid manylinux wheel. Wheels are not allowed to have binary dependencies on each other. This irritates some packages like scipy and numpy, which would love to be able to share thread pools, for example, but that isn't allowed. It is allowed with Conda.
(A few wheels do fake it, though, namely wheels using CUDA, making a "manylinux" wheel that technically is invalid. The WheelNext project is hoping to help with all this.)
There was a problem hiding this comment.
Hmm, any reading that I can look at? The only reference I found is about avoiding global libraries and clashes, but not on binary dependence. I've only looked at PEP600 and PEP513.
Yeah WheelNext would be great. Any indication if this would be available for build-backends to experiments first or will it need pip install frontends interface first?
Yeah more caveats would be in order for this section. I am thinking that this would be useful when the dependent package has a good SOVERSION matching with the pyproject file and the consumer has a good version pinning. Yeah if you do a pip upgrade of the dependency it would potentially break things, but that's true for pure python as well.
I split the general documentation from #1009