1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
# mkwheels
Build a reproducible, pinned Python wheels tarball for vendoring into a
SlackBuild (or any offline `pip install`). Generic over package + version.
## Usage
```
mkwheels <pkg> <ver> [epoch]
```
- `<pkg> <ver>` — the PyPI package and exact version to vendor.
- `[epoch]` — optional `SOURCE_DATE_EPOCH`. Omitted → auto-derived from the
PyPI release upload time (a warning is printed). Pass it to override.
- `OUTPUT` env var overrides the output directory (default: current dir).
Outputs `<pkg>-wheels-<ver>.tar.gz` and `requirements.txt` (pinned + hashed).
Prints the md5sum and the resolved epoch. The `requirements.txt` is an audit
record of the resolved versions, not the install input: the SlackBuild installs
straight from the wheel files (`--find-links`), it does not re-resolve the
lockfile.
## Requirements
`bash`, `python3` + `pip`, `jq`, `curl`, `tar`, `gzip`, `md5sum`.
## Reproducibility
PyPI releases are immutable, so the wheel set for a fixed version is
deterministic. The tarball normalizes tar metadata (sorted entries, fixed
mtime/owner, `gzip -n`) so it is byte-identical for the same inputs + epoch.
Git-sourced dependencies (packages whose upstream pins a git URL) are frozen
at download time: `pip download` resolves whatever is current, and the emitted
`requirements.txt` records the exact resolved versions. Once built, the
tarball is the source of truth.
## SBo integration
Run `mkwheels <pkg> <ver>`, upload the tarball to your package host, and set
`DOWNLOAD_x86_64` / `MD5SUM_x86_64` in the SlackBuild `.info` to point at it.
The SlackBuild then `pip install --no-index --find-links=<wheels>` into a venv.
## Test
`./selftest` builds `six` twice with a fixed epoch and asserts the two wheels
tarballs are byte-identical. Run it after changing the tar/packing logic.
## License
GPLv2 (v2-only). See `LICENSE`. Copyright (C) 2026 Danilo M. <danix@danix.xyz>.
|
