Publish miles-rl wheel to PyPI via Trusted Publishing (Phase 7)

[Shi-Dong]

Summary

• Adds .github/workflows/publish-pypi.yml: publishes the bundled miles-rl wheel to https://pypi.org/ via PyPI Trusted Publishing (OIDC). No long-lived API token in the repo's secrets.
• Bumps setup.py version from 0.2.1 to 0.0.1 — the first public miles-rl release.

Why

Phase 7 of the pip install miles-rl roadmap, completing the journey:

• Phase 1: submodule the patched sglang + Megatron-LM (Add sglang and Megatron-LM as git submodules under third_party/ #1168, Source sglang and Megatron-LM from third_party submodules in docker build #1169, Wire CI to install sglang/Megatron-LM from third_party submodules #1170)
• Phase 2: relocate miles_megatron_plugins, broaden Megatron-LM packaging, pin Megatron-Bridge (Move miles_megatron_plugins into the miles repo as a top-level package #1177, Broaden megatron-core packaging and drop CPU PYTHONPATH override #1188, Pin Megatron-Bridge to an exact commit instead of branch=bridge #1194)
• Phase 4: define extras_require slots (Add empty cpu/gpu/training extras_require slots (Phase 4) #1196)
• Phase 5a: validate publish pipeline against TestPyPI (Add TestPyPI publish workflow (Phase 5a dry-run) #1212)
• Phase 6: bundle the patched forks into a single self-contained wheel (Bundle patched sglang + Megatron-LM into the miles-rl wheel (Phase 6) #1226)
• Phase 7 (this PR): claim the miles-rl name on PyPI and upload the first release.

Why OIDC / Trusted Publishing

• No PYPI_API_TOKEN secret in the repo. Tokens stored in CI are a known leak surface.
• PyPI verifies, per upload, that the GitHub OIDC token's claims match the pre-registered publisher: owner=radixark, repo=miles, workflow=publish-pypi.yml. An attacker who somehow got code into a different workflow couldn't upload as miles-rl.
• The publisher has already been pre-registered on PyPI (miles-rl, publish-pypi.yml, no environment) — confirmed by the project owner.

Safety nets in the workflow

• dry_run defaults to true on workflow_dispatch. Accidentally firing the workflow just builds the wheel; uploading requires explicit dry_run=false.
• Pre-upload version check. Before invoking pypa/gh-action-pypi-publish, the workflow curls https://pypi.org/pypi/miles-rl/<version>/json. If PyPI already has that version (PyPI versions are immutable), the workflow hard-fails with a clear error instead of letting twine return a confusing 400.
• Post-upload smoke install. A fresh python:3.11 venv runs pip install miles-rl==<version> from real PyPI and verifies (via importlib.util.find_spec, no init execution) that the bundled miles, miles_plugins, miles_megatron_plugins, sglang, megatron, megatron.core, megatron.training all land at the expected site-packages paths.

Test plan

• Auto-fired dry-run on push (run 26523348212): wheel built (8.2 MB), no PyPI contact, all upload steps cleanly skipped.
• Manual confirmation gate: before triggering the real upload, project owner explicitly approves. Then gh workflow run publish-pypi.yml --ref shi/phase7-publish-pypi -f dry_run=false. This is the first upload that claims miles-rl on PyPI permanently.
• After upload: pip install miles-rl==0.0.1 on a fresh production-equivalent devbox (image: radixark/miles:dev), then python -c "import miles; import sglang; import megatron.core; import megatron.training; import miles_megatron_plugins.true_on_policy.contracts" with PYTHONPATH unset (this is the real end-to-end test, matching the one we ran on TestPyPI for Phase 6).

Stacked on

radixark/miles PR #1226 (Phase 6 bundling).

Pre-merge cleanup

• Remove the bootstrap push: trigger from publish-pypi.yml once it has landed on the default branch (only workflow_dispatch should remain for subsequent releases).

After this PR merges

For each subsequent miles-rl release:

1. Bump version= in setup.py to a new PEP 440-compliant string.
2. Open a PR with that bump (plus whatever other changes the release contains).
3. After merge, trigger gh workflow run publish-pypi.yml --ref main -f dry_run=false. The wheel is built from main and uploaded.

[gemini-code-assist]

Code Review

This pull request updates the version of the miles-rl package in setup.py from '0.2.1' to '0.0.1' for its first public PyPI release, adding a comment explaining the versioning strategy. There are no review comments, and I have no feedback to provide.

[Shi-Dong]

Superseded. Replaced by a thin packaging slice cut fresh off current `main`:

• Add sglang and Megatron-LM as git submodules under third_party/ #2493 — add `third_party/sglang` + `third_party/Megatron-LM` submodules (pinned at today's `sglang-miles` / `miles-main` tips)
• Publish miles as the miles-rl wheel on PyPI #2495 — `setup.py` bundling, `MANIFEST.in`, `publish-pypi.yml`, `miles-rl` 0.2.2

This branch was 457 commits behind `main` and its submodule pin for sglang was 2831 commits stale and no longer an ancestor of `sglang-miles`. Rebasing it would also have resurrected the `examples/experimental/swe-agent` submodules that #1918 deliberately deleted. The branch is left in place; nothing is lost.