f9d99c50d9
P5 — `.github/workflows/pip-release.yml`: - cibuildwheel matrix per ADR §5.4: manylinux x86_64 + aarch64, macos x86_64 + arm64, win amd64 (5 wheels via abi3-py310 stable ABI — one binary per OS/arch covers Python 3.10–3.13) - Linux aarch64 cross-builds via QEMU; rustup 1.82 pinned in CIBW_BEFORE_ALL_LINUX for reproducibility - Per-wheel smoke test: import wifi_densepose, assert hello()=="ok" - sdist via `maturin sdist` - Trigger: workflow_dispatch + push to `v*-pip` tags ONLY (never on regular commits — won't accidentally publish) - TestPyPI dry-run gate via `repository-url: https://test.pypi.org/legacy/` - Production PyPI publish via Trusted Publisher OIDC (no API tokens in GH secrets per ADR §9). Requires one-time PyPI Trusted Publisher registration before the first publish can fire. - Q3 (witness hash v2 — ADR-117 §11.3) flagged in workflow comments as a hard gate before the first tag. P-tomb — `python/tombstone/`: - Separate `wifi-densepose==1.99.0` sdist+wheel using setuptools backend (NOT maturin — tombstone is pure Python, no Rust). - `src/wifi_densepose/__init__.py` raises ImportError with the migration URL on import. Verified locally: 2.7 KB wheel, `pip install` then `import wifi_densepose` raises ImportError with `pip install wifi-densepose==2.0.0` hint + repo URL. - 5 unit tests (`tests/test_tombstone.py`) lock the file content down: must `raise ImportError`, must contain v2 install hint and migration URL, must NOT contain any `def`/`class`/`import` beyond the bare `raise` — so a well-intentioned refactor can't accidentally bloat the tombstone into a real module that loads partway before failing. Both wheels are published by the same pip-release.yml workflow: - `v1.99.0-pip` tag → publishes tombstone (or via workflow_dispatch with `target: v1-99-tombstone`) - `v2.X.Y-pip` tag → publishes the v2 wheel matrix Per ADR-117 §7.3: tag and publish 1.99.0-pip FIRST so the tombstone claims the "current" slot in pip's resolver, THEN publish 2.0.0-pip. Test count unchanged in main python/ suite (156/156). Tombstone sub-suite: 5 passing. Refs: docs/adr/ADR-117-pip-wifi-densepose-modernization.md §5.4, §7 Refs: #785 Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|---|---|---|
| .. | ||
| src/wifi_densepose | ||
| tests | ||
| .gitignore | ||
| README.md | ||
| pyproject.toml | ||
README.md
wifi-densepose 1.99.0 — tombstone release
This sub-directory builds the tombstone wheel described in ADR-117 §7.2.
wifi-densepose==1.1.0 was published on 2025-06-07 as a pure-Python
FastAPI + PyTorch server. v2.0+ is a hard rewrite around the Rust
crates in v2/crates/ exposed via PyO3.
wifi-densepose==1.99.0 ships no real code — its __init__.py
raises ImportError with a migration URL. The point is that any
project pinned to wifi-densepose>=1,<2 that runs pip install -U wifi-densepose gets a clear, actionable error instead of a silent
import of a broken legacy server.
Build locally
cd python/tombstone
python -m build
Result: dist/wifi_densepose-1.99.0-py3-none-any.whl and the matching sdist.
Smoke-test
pip install dist/wifi_densepose-1.99.0-py3-none-any.whl
python -c "import wifi_densepose"
# Expected: ImportError with the migration URL.
Publish
Publishing is done by the pip-release.yml GH Actions workflow, gated
on a v1.99.0-pip tag OR an explicit workflow_dispatch with
target: v1-99-tombstone. Per ADR-117 §7.3 this should publish
before v2.0.0 to claim the "current" slot in pip's resolver.