Apparently, we distribute pre-built .exe files with pip on all Fedora releases :( $ repoquery --repo=rawhide -l python3-pip | grep exe$ /usr/lib/python3.10/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/w64.exe $ repoquery --repo={fedora,updates} --latest=1 --releasever=35 -l python3-pip | grep exe$ /usr/lib/python3.10/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.10/site-packages/pip/_vendor/distlib/w64.exe $ repoquery --repo={fedora,updates} --latest=1 --releasever=34 -l python3-pip | grep exe$ /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe $ repoquery --repo={fedora,updates} --latest=1 --releasever=33 -l python3-pip | grep exe$ /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe The actual python-distlib package removes those in %prep. I think we should do the same.
This also affects RHEL 9 (for Python 3.9) and RHEL 8 (for Python 2.7, 3.6, 3.8, and 3.9). [root@fff08df4321d /]# find /usr/lib -name '*.exe' /usr/lib/python3.6/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/w64.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.8/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.8/site-packages/pip/_vendor/distlib/w64.exe /usr/lib/python3.8/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.8/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe /usr/lib/python2.7/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python2.7/site-packages/pip/_vendor/distlib/w64.exe /usr/lib/python2.7/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python2.7/site-packages/pip/_vendor/distlib/t64.exe This does also affects RHEL 7 (for Python 2.7): [root@3715e294e7ae /]# find /usr/lib -name '*.exe' /usr/lib/python3.6/site-packages/pip/_vendor/distlib/w32.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/w64.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/t32.exe /usr/lib/python3.6/site-packages/pip/_vendor/distlib/t64.exe
> This does also affects RHEL 7 (for Python 2.7) I've meant for Python 3.6. We don't ship pip for 2.7 there.
FYI it seems like distlib/*.exe are generated from PC/launcher.c. Example: https://bitbucket.org/pypa/distlib/commits/774bc70bfb283be10f409a78d79fdfa751041b08
I wonder what are they used for and if upstream pip even needs to bundle them. If we could adapt their tooling to drop it for us :/
(In reply to Miro Hrončok from comment #5) > I wonder what are they used for and if upstream pip even needs to bundle > them. If we could adapt their tooling to drop it for us :/ I think they are actually used when installing wheels on Windows systems, so we need to drop them downstream.
PC/launcher.c is a wrapper used as <venv>\Scripts\python.exe to launch Python using <venv>\pyvenv.cfg configuration. <venv>\Scripts\python.exe is not Python. It's a completly different program which is only responsible for locating the real python.exe and start it. In short, yes, it is useless on Linux :-) About the license, PC/launcher.c comes from Python, so it is under the PSF License Agreement: https://docs.python.org/dev/license.html I don't know exactly what the .exe binaries contain, they are likely built by the MSC compiler (of the Windows SDK, or using Visual Studio).
Removing the binaries in prep is a good idea, but you could also patch out the inclusion line in setup.py:https://github.com/pypa/pip/blob/b5457dfee47dd9e9f6ec45159d9d410ba44e5ea1/setup.py#L67
I suppose that removing the binaries in prep is safer, but OTOH *also* removing that line might be needed. Thanks, Nick.
PR: https://src.fedoraproject.org/rpms/python-pip/pull-request/95
FEDORA-2021-8def566b68 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8def566b68
FEDORA-2021-8def566b68 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-eefb815329 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-eefb815329
FEDORA-2021-ec57c5de64 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec57c5de64
FEDORA-2021-93e4d875e1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-93e4d875e1
FEDORA-2021-eefb815329 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-eefb815329` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-eefb815329 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-ec57c5de64 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ec57c5de64` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec57c5de64 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-93e4d875e1 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-93e4d875e1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-93e4d875e1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-ec57c5de64 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-93e4d875e1 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-eefb815329 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-446b0b621c has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-446b0b621c