Package: consolidatewheels
Supported PlatformsLinuxOSXWindowsIntroductionWhen multiple wheels depend on each other and share some.sofiles,
it is possible to rely onauditwheel--excludeto make sure the.sois included in only one of the wheels to avoid duplicating the file in every package.That allows Python wheels to share the same.soas far as at least one of them
is loading them in memory. Seehttps://github.com/pypa/auditwheel/issues/76andhttps://github.com/pypa/auditwheel/pull/368for discussions on the topic.The problem with this approach is that the package where the.sois included
will have the library name mangled byauditwheel, while the ones where it’s
excluded will reference to the library with its original name.Suppose you havelibone.whlandlibtwo.whlboth depending onlibfoo.so,
andliboneis a dependency oflibtwoso you already know you can includelibfoo.soonly inlibone.whl, you could do:auditwheel repair dist/libone.whl
auditwheel repair dist/libtwo.whl --exclude libfoo.soIn such case you would end up with the following wheels:venv/lib/python3.10/site-packages/libone
├── __init__.py
├── _libone.cpython-310-aarch64-linux-gnu.so
venv/lib/python3.10/site-packages/libone.libs
└── libfoo-ef63151d.so
venv/lib/python3.10/site-packages/libtwo
├── __init__.py
├── _libtwo.cpython-310-aarch64-linux-gnu.soThe problem would be that while_libone.cpython-310-aarch64-linux-gnu.sowas patched byauditwheelto know about thelibfoo-ef63151d.soname,_libtwo.cpython-310-aarch64-linux-gnu.sowas not, and so still refers to the
original name:$ ldd venv/lib/python3.10/site-packages/libone/_libone.cpython-310-aarch64-linux-gnu.so
    libfoo-ef63151d.so => ../libone.libs/libfoo-ef63151d.so (0x0000ffff8f8f0000)

$ ldd venv/lib/python3.10/site-packages/libtwo/_libtwo.cpython-310-aarch64-linux-gnu.so
    libfoo.so => not foundWhich means that trying to importlibtwowill fail with:ImportError: libfoo.so: cannot open shared object file: No such file or directoryWhich makes sense, because we actually providedlibfoo-ef63151d.soand notlibfoo.so.To solve this problemconsolidatewheelswill patch all provided wheels to make sure that they
share a single naming convention for libraries that were mangled.Afterconsolidatewheelsis used, the final result would be:$ ldd venv/lib/python3.10/site-packages/libone/_libone.cpython-310-aarch64-linux-gnu.so
    libfoo-ef63151d.so => ../libone.libs/libfoo-ef63151d.so (0x0000ffff8f8f0000)

$ ldd venv/lib/python3.10/site-packages/libtwo/_libtwo.cpython-310-aarch64-linux-gnu.so
    libfoo-ef63151d.so => not foundwhich would work correctly as far asliboneis imported _before_libtwoas they will
both look forlibfoo-ef63151d.sowhich was loaded already bylibone.Linux Supportconsolidatewheelsworks also in conjunction withauditwheel, consolidating all libraries
embedded byauditwheel. But on Linux duplicates won’t be removed automatically, so
you need to make sure to useauditwheel--excludeto ensure libraries are not embedded twice.OSX Supportconsolidatewheelsworks also in conjunction withdelocate, consolidating all libraries
embedded bydelocateand removing duplicates of the embedded libraries when they are provided
in multiple wheels.Windows Supportconsolidatewheelsworks also in conjunction withdelvewheel, consolidating all libraries
embedded bydelvewheeland removing duplicates of the embedded libraries when they are provided
in multiple wheels.InstallInstall with:$ pip install consolidatewheelsNote thatconsolidatewheelsrequirespatchelfto be available in the system,
and it only works onLinuxsystems. But those are the same requirements thatauditwheelhas, so you are probably already satisfying them if you useauditwheel.UsageUsage instructions:consolidatewheels --helpExample:consolidatewheels libone.whl libtwo.whl --dest=./consolidated_wheelsFor a more complex example and a testing environment, you can take
a look athttps://github.com/amol-/wheeldepswhich usesconsolidatewheels