Distutils-SIG April 2021

distutils-sig@python.org

4 participants
3 discussions

Re: Packaging optional, arch-dependent, pre-built libraries

by Tzu-ping Chung

“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

17 hours, 30 minutes

Packaging optional, arch-dependent, pre-built libraries

by Vincent Pelletier

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

5 days, 18 hours

Making setup.py run external command to build

by Julian Smith

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

1 week, 2 days

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG April 2021