記事一覧へ戻る
公式資料から考えたSkill案 開発フロー

SKILL ARTICLE / python-build-details-inspector

Pythonを起動せず、ビルドの違いを確かめる

Pythonを動かす前に、配布物が示すビルド条件を読む。

Python 3.14以降の`build-details.json`を固定版のJSON Schemaで検証し、言語・実装のversion、platform、ABI、拡張suffix、C APIの情報を、確認できない事項と分けて整理するSkill案です。

この記事で紹介するSkill案は、参考資料を読んだうえで私が考えたものです。参照先が提供・評価・推奨しているものではありません。

OVERVIEW → CAN DO → BUILD

知ったことをSkillづくりに活かす

1 — OVERVIEWPythonビルド情報インスペクター

Pythonのbinaryを起動できない場面でも、固定schemaの静的ファイルを読むと、言語・実装のversion、platform、ABI、拡張suffixなどの宣言を同じ形式で比べられる。

2 — CAN DOできるようになること

未知のPythonを起動する前に、配布物が宣言するversion、platform、ABI、拡張suffixと、追加確認が必要な事項を根拠付きで分けられる。

3 — BUILD実行せずに確認できる入口を選ぶ

PEP 739は、interpreterを動かせない交差compileやlauncherの場面を想定し、静的なJSONを入口にします。自分たちのSkillでも、未知のbinaryを起動する前にmanif...

01 / OVERVIEW

資料の概要

PEP 739は、Pythonインストールのビルド情報を静的に記述する`build-details.json` 1.0の公式仕様です。AcceptedのStandards Track PEPで、対象versionはPython 3.14です。確認したPython PEPsリポジトリのsnapshotはcommit `24419b92ae550bf2878716f57c257cba00d3c1a1`、PEP本文の最終変更は2025年2月6日、仕様本文はPublic DomainまたはCC0-1.0-Universalです。

仕様では、Python 3.14以降のインストールは、技術的に実現できない場合を除き、platform非依存の標準ライブラリディレクトリへ`build-details.json`を置きます。形式version 1.0の必須情報は`schema_version`、`base_prefix`、`platform`、`language`、`implementation`です。ABI、import可能なファイルのsuffix、libpython、C APIなどは、その実装や配布物が該当する場合に記録されます。pathは絶対pathの場合と、ファイル位置または`base_prefix`を基準にする相対pathの場合があります。

2026年9月8日の確認では、Python 3.14.7公式macOSインストーラのSHA-256が公開ページの値と一致しました。通常版とfree-threaded版から対象Pythonを起動せずにファイルを抽出し、PEPの固定JSON Schemaで両方がvalidになることを確認しました。通常版の`abi.flags`は空、拡張suffixは`.cpython-314-darwin.so`で、free-threaded版はflagに`t`を持ち、suffixは`.cpython-314t-darwin.so`でした。これは確認した2配布物の差であり、他のOS・実装・配布元へ一般化しません。この記事のSkill案はPython Software FoundationやPEPが提供・評価・推奨するSkillではなく、仕様をビルド差分の確認手順へ読み替えた記事側の提案です。

02 / CAN DO

できるようになること

Skill案では、利用者から渡されたPython 3.14以降の配布物または展開済みディレクトリから`build-details.json`を探し、対象ファイルを実行せずに読みます。まずファイルサイズとJSON構文を確認し、`schema_version`に対応する固定版schemaで検証します。その後、言語と実装のversion、platform、ABI flags、拡張suffix、libpython、C APIを定型表へ整理します。2つの配布物を比べる場合は、同じfield同士の一致・差・欠落だけを示します。

このファイルはインストール全体で一定のビルド情報が対象です。仮想環境固有の`site-packages`、導入package、環境変数、実行時の状態は範囲外です。schemaに通ることは、記載内容の真正性、配布物の安全性、拡張moduleの互換性を保証しません。ファイルがない場合も、Python 3.13以前なのか、技術的制約のある配布物なのか、標準外の場所なのかを区別できなければ「判定不能」とします。未知のpathは自動で開かず、interpreterや共有library、拡張moduleを実行・loadしません。

USE CASES Python配布物の比較交差compileの事前確認C拡張の切り分け

活かしやすい場面

  • CIとローカルで異なるPython配布物のビルド条件を比べる
  • 交差compile用のPythonを実行せずに情報を確認する
  • C拡張の調査前にABIとsuffixの宣言を整理する

使う前に確認したい場面

  • Python 3.13以前にも同じファイルが必ずあると仮定する調査
  • 仮想環境のpackage一覧や`site-packages`を確認する作業
  • schema適合だけで配布物の真正性・安全性・互換性を保証する判断

03 / BUILD

自分たちのSkill作成に活かせること

文章やコードをそのまままねるのではなく、自分たちのSkillに取り入れたい判断基準や工程の分け方を整理しました。

01

実行せずに確認できる入口を選ぶ

PEP 739は、interpreterを動かせない交差compileやlauncherの場面を想定し、静的なJSONを入口にします。自分たちのSkillでも、未知のbinaryを起動する前にmanifest、schema、hashなどの非実行情報から確認を始める設計にできます。

02

schema適合と意味の判断を分ける

JSON Schemaはfieldの型や必須項目を検証できますが、値の真正性や用途への適合までは保証しません。Skillの出力を「schema検証結果」「記載された事実」「追加確認が必要な判断」に分けると、validという一語から互換性を過信するのを避けられます。

03

欠落を否定へ読み替えない

ABIやlibpythonなどには実装・配布物の条件に応じたfieldがあります。また、仕様は技術的に難しい場合のファイル欠落も認めています。Skillでは、fieldやファイルがないことを機能なしと即断せず、対象version、配布元、配置、実装条件を追加確認へ回します。

04 / WORKFLOW

Skillにするときの流れ

  1. 01

    非実行で取得

    配布元、Python version、取得方法とhashを記録し、展開済みの`build-details.json`だけをサイズ制限付きで読む。

  2. 02

    固定schemaで検証

    `schema_version`を確認し、対応する固定版JSON Schemaで構文、必須field、型、追加fieldの扱いを検証する。

  3. 03

    差と不明点を分離

    version、platform、ABI、suffix、library、C APIを比較し、欠落と範囲外の情報は推測せず追加確認として返す。

05 / TRY

試すときに使える依頼文

これは完成したSkillではありません。先に依頼文として試し、期待する結果が返ってくるかを確かめるための試作プロンプトです。

PROMPT.txt
このPython配布物を実行せずに、`build-details.json`からビルド条件を確認してください。配布元、Python version、取得方法、hashを記録し、ファイルサイズとJSON構文を確認してから、`schema_version`に対応する固定版schemaで検証してください。言語・実装のversion、platform、ABI flags、拡張suffix、libpython、C APIを表にし、欠落、schema外、環境固有で確認できない事項を分けてください。記載pathは自動で追跡せず、interpreter、共有library、拡張moduleは実行・loadしないでください。互換性や安全性は断定しないでください。

06 / BUILD BRIEF

試作するときの設計メモ

これは配布済みのSkillではありません。対象を小さく絞り、停止条件と評価ケースを足しながら確かめるための出発点です。

BUILD-BRIEF.md
Python 3.14以降の`build-details.json`を非実行で検証し、ビルド条件を比較するSkillを作る。
入力は配布物または展開済みディレクトリとし、配布元、version、取得方法、hashを記録する。対象JSONへサイズ上限を設け、構文と`schema_version`を確認してから対応する固定版JSON Schemaで検証する。
言語・実装のversion、platform、ABI flags、拡張suffix、libpython、C APIを定型で出力し、2件比較では一致・差・欠落をfield単位で示す。環境固有情報、schema外の意味、真正性、互換性は別判断として扱う。
未知のpathを自動追跡せず、interpreter、共有library、拡張moduleは実行・loadしない。未対応schema、過大・不正JSON、配置理由を確認できない欠落では停止する。

07 / WATCHOUTS

人が確認するところ

  • 未知の`base_interpreter`、共有library、拡張moduleを実行・loadしません。記事の手順はJSONを読む範囲に限定します。
  • 入力内のpathは宣言として扱い、自動で追跡しません。相対pathを扱う場合も展開元の外へ出ないことを確認します。
  • schema適合は真正性や互換性の証明ではありません。配布元とhash、用途別の互換性条件は別に確認します。
  • `build-details.json`は環境固有情報を対象にしません。仮想環境や導入packageの状態をこのファイルから推測しません。

次の学びも、見逃さずに。

ブログ・AIプロンプト・Skills・研究・読書の更新を、RSSリーダーでまとめて購読できます。

RSSを購読する

Loading...