- Builds manylinux, macOS 10.9+, and Windows wheels for CPython and PyPy - Works on GitHub Actions, Azure Pipelines, Travis CI, AppVeyor, CircleCI, and GitLab CI - Bundles shared library dependencies on Linux and macOS through auditwheel and delocate - Runs your library's tests against the wheel-installed version of your
Is there some easy way to solve this specifically with cibuildwheel?
https://github.com/joerick/cibuildwheel :
library
On Mon, Apr 5, 2021, 12:18 Tzu-ping Chung
If a file is not built or linked against, a dll in your wheel is essentially a plain data file from Python packaging’s perspective, no different from e.g. a text file. So you’re looking in the wrong direction for solutions.
I believe the issue PyInstaller has with your package is that, since PyInstaller compiles a program into an executable, ctypes.util.find_library() won’t work (since there is no actual dll to find). If you know for sure the dll will be available, you can copy the binary to a temporary location (the “official” way to do this is through importlib.resources.path[1]), and use the path to load the dll directly instead.
[1]: https://importlib-resources.readthedocs.io/en/latest/
-- Tzu-ping Chung (@uranusjr) uranusjr@gmail.com https://uranusjr.com
On 03/4/2021, at 06:57, Vincent Pelletier
wrote: Hello,
I'm the author of python-libusb1, a pure-python ctypes wrapper for libusb1.
Until recently, I had been purely relying on OS-linker-provided libusb1 (distro-installed on GNU/Linux and *BSD, fink/macports/... on OSX, ...).
Then, I've been requested to bundle the libusb1 dll on windows (x86 and x86_64 wheels) because otherwise distributions seems exceedingly painful for applications using my module. With some extra code to setup.py to fetch, unzip and copy[1] the dlls, plus a now even more multi-stage distribution process (sdist, both windows wheels, in addition to the existing sign and twine steps), and it ipso facto works.
Now, I'm asked to add pyinstaller compatibility, as it on its own overlooks the dll. Which makes me feel that I am maybe not using the best possible way to bundle these.
From my reading of distutils and setuptools, my understanding is that a package is that non-pure-python packages contain: - stuff they built themselves (build_ext & friends) - third-party libraries that the stuff they built themselves is linked against Having nothing to build, I cannot seem to reach the library inclusion step.
What is the recommended way of bundling a third-party-built arch-dependent library in an otherwise pure-python package ?
[1] https://github.com/vpelletier/python-libusb1/blob/49f7f846bdd3c3d0f2ec3a01c2...
Regards, -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/J6DDM...
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/OBAR3...