On Sun, 2021-04-11 at 00:59 +0000, Vincent Pelletier wrote:
> Hello,
> 
> On Tue, 6 Apr 2021 00:17:32 +0800, Tzu-ping Chung <uranu...@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/4fa6df2753ded1bcc1ce2fdd8046f78bd240ff7647f5c9bcf547c0df77e3/zipp-3.4.1.tar.gz#sha256=3607921face881ba3e026887d8150cca609d517579abe052ac81fc5aeffdbd76
>   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 pi
> p 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 pi
> p 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
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@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/QGADIRT27SW7B3WXTI4X2VB5EC6EYHUE/

Can you share in more detail how find_namespace is being used? Python 2.7 does
not support namespace packages, I'd say you probably don't really to use them
anyway, putting a __init__.py in the target package folder and using the find
directive instead should solve the issue.

Cheers,
Filipe Laíns

Attachment: signature.asc
Description: This is a digitally signed message part

--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@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/FQXAR63ZQMCBKGP7EIRATSSVWWE7W6DT/

Reply via email to