New package request: CommonsLang_Python (Python toolchain for dk0)

[jonahbeckford]

Package request: CommonsLang_Python

Requested package: CommonsLang_Python (a dk Python toolchain / runtime)

Purpose: give dk0 a Python toolchain so it can install and run Python and ingest PyPI
distributions, unblocking the dk-ai skill convert-pypi-to-dk-package (name reserved in
the dk-ai AGENTS.md inventory) and the many Python/PyPI-dependent mini-plans the Prompt
Studio produces.

Suggested modules

• A Uv module that installs and manages Python environments (uv / venv).
• Wheel / sdist ingestion so a PyPI distribution can become a dk package.

Upstream: CPython (python.org), PyPI; uv (github.com/astral-sh/uv) for environment management.

Build method: toolchain / runtime (prebuilt Python + uv, with wheel ingestion at consume time), analogous to the existing CommonsLang_OCaml / CommonsLang_Rust / CommonsLang_DotNet toolchains.

Why now (evidence): in the dk Prompt Studio round-4 optimization (2026-07-23), convert-pypi-to-dk-package is the top missing-skill demand (x9 of the dev cases). A verified investigation of the dk0 docs and dkpkg catalog found NO Python path today: no CommonsLang_Python, no dk0 command that consumes a wheel/sdist, and no from-source Python build path (only autoconf and CMake for C/C++). So this is a building-block gap, not a missing recipe: the skill cannot be authored truthfully until this package exists.

Filed automatically from the dk Prompt Studio optimization round.

[jonahbeckford]

CommonsLang_Python is implemented, released, and signed.

• Repo: dkpkg/CommonsLang_Python
• Release: 0.1.202608031217 (latest), built and attested for all four ABIs — Windows_x86_64, Linux_x86_64, Darwin_x86_64, Darwin_arm64.
• Contents: CPython 3.13.14 (python-build-standalone) + uv 0.12.1 runtime, plus lock-then-build PyPI ingestion — UvLock (author-time uv lock → slot-aware dk-uv-lock.jsonc) and UvBuild (offline, hash-pinned wheel fetch; never solves at build time).
• Signing: openbsd-signify producer key + GitHub SLSA v1 L2 attestation (values.json.sigstore.jsonl).
• Consume: dk0 add github-l2 dkpkg/CommonsLang_Python.

Marking implemented.

[jonahbeckford]

Correction: removing implemented.

The 0.1.202608031217 release exists and passes distribute + attestation across all four ABIs, and the CPython/uv runtimes materialize. But the toolchain's actual build/ingest path is not yet validated end-to-end — running python/uv via the dk run rules, creating a lock with UvLock, and building a project with UvBuild. Leaving implemented on would tell the optimizer the toolchain is usable before that is true.

Removing the label until the lock-then-build path is exercised on a real project and captured as a dk-ai skill. The release itself and its signing are unaffected.

[jonahbeckford]

Implemented, validated end to end, and released green across all four ABIs.

Release: CommonsLang_Python 0.1.20260807000030 (dkpkg/CommonsLang_Python, commit 187d3c6) — distribute + combine + attest all green for Windows_x86_64, Linux_x86_64, Darwin_x86_64, and Darwin_arm64; signed.

Unlike the earlier 0.1.202608031217, the PyPI ingestion is now actually exercised, not just distributed:

• Lock — UvLock.Solve resolves a requirement set into a slot-aware dk-uv-lock.jsonc (validated for six, markupsafe, and the full requests closure).
• Build — UvBuild.Build fetches each pinned wheel offline via dk get-asset (content-addressed, no PyPI at build time) and uv pip install --no-index --offlines the closure; imports succeed, including the compiled charset_normalizer.

The reusable recipe is captured as the dk-ai skill convert-pypi-to-dk-package.

Getting the re-release green surfaced and fixed a dk0 cross-build issue: F_TarToZip slotted the whole-tree SDK.Zip by execution ABI, so on a macOS re-release the native arm64 job (both macOS jobs execute on arm64 since GitHub retired x86_64 runners) restored the x86_64 SDK.Zip. Fixed structurally in CommonsBase_Std 2.6.20260806174029 (F_TarToZip now slots at Release.target_abi), with CommonsLang_Python re-pinned and fetching the interpreter at the target ABI.