“setup.py install” is pretty ancient at this point and lacks many of the remotely modern packaging syntax.
I’d strongly advise to ignore it entirely. Use “pip install .” instead.
--
Tzu-ping Chung (@uranusjr)
uranusjr(a)gmail.com
https://uranusjr.com
> On 11/4/2021, at 08:59, Vincent Pelletier <plr.vincent(a)gmail.com> wrote:
>
> Hello,
>
> On Tue, 6 Apr 2021 00:17:32 +0800, Tzu-ping Chung <uranusjr(a)gmail.com> wrote:
>> 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.
>
> Thanks, I somehow did not get this until I saw it spelled out.
>
> There seems to be one catch, though: once I list the dll in
> package_data, it gets copied over to build/lib*, and the same dll gets
> used for all distributions, so if I build the win32 wheel first:
> - plat=win_amd64 gets a 32bits dll
> - plat=any gets a windows 32bits dll
> so I now have to clean --all between each.
>
> For a text file it could make no difference (although there are the EOL
> shenanigans which would arguably be platform-specific). So while I now
> agree the dll should be treated by my setup.py as a "plain data file",
> there is this annoying extra complication layer.
>
>> 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.
>
> Thanks for the pointer, I would love to use it. Unfortunately, this
> fails to install on 2.7:
> with
> install_requires=(
> "importlib_resources<=4.0.0;python_version<'3.0'",
> "importlib_resources;python_version>='3.0' and python_version<'3.7'",
> ),
> I get
> $ ./vpy2/bin/python setup.py install
> [...]
> Installed /home/vincent/git/python-libusb1/vpy2/lib/python2.7/site-packages/libusb1-1.9.2+4.g5aeb636.dirty-py2.7.egg
> Processing dependencies for libusb1==1.9.2+4.g5aeb636.dirty
> Searching for zipp>=0.4
> Reading https://pypi.org/simple/zipp/
> Downloading https://files.pythonhosted.org/packages/38/f9/4fa6df2753ded1bcc1ce2fdd8046f…
> Best match: zipp 3.4.1
> Processing zipp-3.4.1.tar.gz
> Writing /tmp/easy_install-ZDtgKM/zipp-3.4.1/setup.cfg
> Running zipp-3.4.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-ZDtgKM/zipp-3.4.1/egg-dist-tmp-GmefKD
> DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
> DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
> error: find_namespace: directive is unsupported on Python < 3.3
>
> The contributor who requested pyinstaller support somehow got this to
> work with my archaic and unfortunately very zip-hostile
> os.path.join(dirname(__file__), 'libusb-1.0.dll')
> so I will be continuing with this until I finally drop 2.7 support.
>
> Regards,
> --
> Vincent Pelletier
> GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1
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/49f7f846bdd3c3d0f2ec3a01c…
Regards,
--
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1
Hello
I have a project with a fairly involved build process where we generate
C++ via a python-clang-based code analyser, generates Python bindings
for the resulting C++ API with SWIG, and finally compile and link to
create various .so's and .py files.
I'd like to package things up with a setup.py script, but from what i
have read, it looks like distutils expects to compile, link and run
swig itself, using distutils.core.setup()'s ext_modules arg?
Is there a way to write setup.py so that it instead runs an external
command (e.g. 'cd foo && make all') when it is asked to build?
Thanks for any help,
- Jules
--
http://op59.net