-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow not copying .so
files provided by other PyPI packages (e.g. libtorch*.so
from torch
)
#391
Comments
This would be helpful for NumPy/Scipy as well in order to consume a common openblas shared object. xref MacPython/openblas-libs#86. The delocate facility for macOS will need a similar fix, it is used in macOS wheel building by multibuild and cibuildwheel. |
While this would work in simple environments but there's nothing that enforces the 2 packages to live in the same
|
Good point. One way out of that is shipping the library with an importable Python component, so you can query the location (just like pybind11 and numpy do for their headers). And then preload the shared library. In fact, this is necessary anyway on Windows, because there is no rpath. NumPy and SciPy do it like that for the vendored OpenBLAS: https://github.com/scipy/scipy/blob/main/tools/openblas_support.py#L206 |
Or maybe even easier, ship it as a Python package that one can import, and the |
If we leave the rpath mangling out of this PR, then all we require from auditwheel is to be able to extend the allowlist from a command line option like in #368 |
On second thought, maybe in @rgommer's scheme no support is required from auditwheel, since the loading done by |
even with @rgommers suggestion (I was about to post the same when I saw this had been updated), it needs an update from auditwheel (likely #368) because the c-extension will still reference the soname from
Almost sure you meant that but, you still have to preload, it's just that you've moved the complexity of the actual job to a single place ( I'm sure this works on glibc linux & windows. I've not tested this on musl linux or macOS. |
Kinda. I meant that that Python package could have a private function that uses for example the CPython C API and does a single dummy call in its |
OK, I guess something like:
with |
yes, that seems reasonable. Then the package being examined by auditwheel does not explicitly link to |
no changes are needed for the |
This is in fact a duplicate of #76 |
That's probably what @mattip meant. @mattip maybe it's worth building an |
Good idea. I will work on this in the coming days. |
Following #391 (comment), I tried:
to (add a new nest level without changing the package name and soname)
where: # package/nested/__init__.py
from . import _init and // _init.c
#include <Python.h>
PyMODINIT_FUNC PyInit__init(void) {
PyObject *m = PyImport_ImportModule("package.nested._C._C");
if (m == NULL) {
return NULL;
}
PyObject *sys_modules = PyImport_GetModuleDict();
PyDict_SetItemString(sys_modules, "package.nested._C", m); // change `sys.modules` entry back
return m;
} command-line: gcc --shared -Wall -O3 -fPIC -I$CONDA_PREFIX/include/python3.8 -L$CONDA_PREFIX/lib \
_init.c -o package/nested/_C/_init.abi3.so EDIT: EDIT: For the members of Before: >>> import package.nested._C
>>> package.nested._C
<module 'package.nested._C' from '.../package/nested/_C.so'>
>>> package.nested._C.submodule
<module 'package.nested._C.submodule'>
>>> package.nested._C.MyClass
<class 'package.nested._C.MyClass'>
>>> package.nested._C.MyClass.__module__
'package.nested._C'
>>> package.nested._C.my_function.__module__
'package.nested._C' After: >>> import package.nested._C
>>> package.nested._C
<module 'package.nested._C._init' from '.../package/nested/_C/_init.abi3.so'>
>>> package.nested._C.submodule
<module 'package.nested._C._C.submodule'>
>>> package.nested._C.MyClass
<class 'package.nested._C._C.MyClass'>
>>> package.nested._C.MyClass.__module__
'package.nested._C._C'
>>> package.nested._C.my_function.__module__
'package.nested._C._C' an extra level of the soname path is added to |
auditwheels
copies all external.so
files into<packagename>.lib
folder. Then packs them into the wheel file. Sometimes the current package (the developer what to audit) only has very small C++ extension, but it references a large.so
file. For example, the user builds a C++ extension for PyTorch, it referenceslibtorch*.so
(some files up to 0.5GiB+). This makes the final wheel file extremely large (~2GiB).We can add an option that if the
.so
files are located insidesite-packages
, then do not copy them but update therpath
of the target.For example, the user builds a C++ extension for PyTorch, it references
libtorch_python.so
.auditwheel
can update therpath
to:where
$ORIGIN/..
issite-packages
. And then addstorch
to the install dependency.The text was updated successfully, but these errors were encountered: