-
Notifications
You must be signed in to change notification settings - Fork 315
Include wheels in distribution #1481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for the pertinent remark:
So:
|
So:
|
And how to right now generate a requirement.txt with Sha 256 ? I think pip is not ready for that yet, isn't it ? |
I don’t believe so… however Per this issue the hashes seem to be for wheels of the selected platform. Also somewhat related and could be useful: astral-sh/uv#1681 |
so, after a looong fight, published:
|
last problem... down to winpython wheel or not to wheel , the complex one |
I would be curious to see if it changes the size of the distribution. It might be beneficial to test it out as an alpha build (experimental)? Let me know if you would like support with anything! I can try forking the project and testing things out if there’s guidance anywhere on how to build the executables/shims 😄 |
I would bet it will double the size, unless the wheel comitee decides to allow a better compression format, like zstd |
... need to rethink the build system |
replaying the idea, to feel the pain points:
size of wheels:
fight non-whl format wheels, 8 wheels: filterpy, pywinusb, simplegeneric, docopt, intervaltree, MarkupSafe, msgpack, sspyrs |
Confirmed:
I was able to get down to 687 MB using maximum compression settings with 7z. 7z a -t7z -mx9 -myx9 -mf=BCJ2 -m0=LZMA2:d3840m:fb273 -ms -mmt2 -slp wheels.7z wheels\ It is still ~100 MB larger than it was previously. This is a problem because the maximum file size for VirusTotal uploads is 650 MB 🤔 Wheels are better than sdist because user doesn't have to worry about building them. But the compression could be better and they have additional metadata bloating the wheel file size that is more valuable to the package manager than the user. |
The natural bad trend on wheel size balooning is hard to fight:
|
what shall be the format of a pip freeze + hashtag file ? |
I found out that it is still possible to validate the checksums of Python packages after they have already been installed. The hashes of all the package files in Method ATo generate a reproducible and standalone environment with installed packages:
|
Alternative to the powershell one-liner... this little python script will check hashes of wheels in a directory against a
|
On the wheel summit, that happened March 21, 2025, 9AM-1.30PM @ META - Menlo Park, CA:
There was a discussion 4 years ago, hinting to zstd-19 being 40% better : https://discuss.python.org/t/making-the-wheel-format-more-flexible-for-better-compression-speed/3810/23 |
Good news: PEP 751 was accepted and includes a |
I saw, that is the breakthrough needed for the idea.
experiment
so:
and to restores wheels:
gives :
|
so, apparently:
|
doing an extreme proof-of-concept example using zstandard-0.23/zstd-1.5.6:
so... to remain equivalent in size of a "full" Winython download, having wheelnext advocating for tar.zst at compression level 12 would be the ideal solution, to make the idea "neutral" in Wheelhouse-included download size of WinPython. Level 12 is the last "fast" level of zstd, based on old stackoverflow post here
|
Apparently, "pip" will be very slow to include PEP-751 lockfile.toml, like 2026. to be then used as
|
Comparing wheels from internal wheelhouse and pypi, via hash-256:
Remains:
|
pypandoc problem is fixed intervaltree has no good solution:
WinPython wheel doesn't make sense yet, it's a bit a fire-and-forget with each release, WinPython way of free support. ....further brewing needed. |
I did preparre a prototype of an ugly post-hash generator, to track down the not-from-pypi-default wheels:
problem: how to know it's a correct lockfile generator
|
PEP 784 is accepted; Zstandard arrives in the standard library https://peps.python.org/pep-0784/ |
we are at step1: STANDARD lockfiles are generated during build process, per standard pip-25.1.1 |
I want to propose that WinPython include the original wheels in the distribution instead of a pre-installed/configured Python environment. This has two benefits.
The first benefit is that it allows the users to verify the integrity of the
.whl
files for tampering, by confirming that the SHA256 of the wheel files match the ones in PyPI. This is excellent from a security standpoint.The second benefit is that it would allow users the flexibility to create virtual environments and install only the packages that they need into them using
pip install
oruv pip install
. This is preferred over puttingC:WinPython\python\Scripts
andC:\WinPython\python
on the system PATH, because it allows for dependency isolation in projects and avoids the need for a mutable system environment.The only downside is that WinPython users would have a bit of initial setup to do. They would need to create the venv and pip install the packages they need. I would argue that this is a universal practice in Python that every user should know how to do... but WinPython could still provide a helper script (i.e.
setup.bat
) to take care of it.From WinPython root, create
requirements.txt
containing all WinPython packages:Note that in my testing with WinPython
3.13.1.1slimb2
I had to manually remove the following packages fromrequirements.txt
becausepip download
could not find these pinned versions on PyPI:adodbapi==2.6.1.3
baresql==0.8.0
db.py==0.5.4b1
formlayout==1.2.1a1
pdfrw==0.4.post2
ppci==0.5.9
PySimpleGUI==4.60.4
sqlite_bro==0.13.1
winpython==11.4.20250119
Assuming the new WinPython distribution has a
wheels
directory instead of pre-installed packages, usesetup.bat
script after unzipping:From WinPython root:
cd python python -m venv .venv --prompt WinPython .venv\Scripts\activate pip install --no-index --find-links=wheels/ -r requirements.txt
After running
setup.bat
, users can either putC:\WinPython\.venv\Scripts
on the PATH or activate it usingC:\WinPython\.venv\Scripts\activate
when they need to work 😄The text was updated successfully, but these errors were encountered: