python-env-manager

Python 環境マネージャー

環境マネージャーを検出し、適切なコマンドでインストールします。data-science-python-stack と、依存関係の追加が必要なワークフロースキルの唯一の情報源です。

次のステップへの案内 — このスキルの後に進む先

ここに来た経路…	インストール後の次の関門…
organize-ml-workspace § scaffold	→ organize-ml-workspace § Editable workspace package；scaffold を続行
audit-ml-pipeline § agent-feature-missing	→ audit-ml-pipeline に戻る；audit/<stem>.py を配置
build-ml-pipeline / evaluate-ml-pipeline § missing dep	→ 呼び出し元のスキルに戻る；失敗した事前チェックの項目から続行
data-science-python-stack § Missing dependency	→ 呼び出し元に戻る；不足していたインポートが成功するはずです

ターンを完了と宣言する前に、証拠を添えて事前チェックリストを必ず再提示してください。

停止条件 — 最初に必ず読むこと

• 曖昧さを説明しても、解決したことにはなりません。 競合（「conda の myenv がアクティブですが、ルートに pixi.toml があります」）を挙げたうえで、ユーザーに代わって選ぶのは質問ではありません。2 つのマネージャーが見つかった場合、選択するのはユーザーです。AskUserQuestion を使って質問してください。そのツールが利用できず、すでに 2 つのマネージャーが検出されている場合は、BLOCKED: manager ambiguity needs a user decision (<why the tool did not run>) を報告して停止してください。一方を「状況情報であり、選択肢ではない」と宣言して質問を打ち切ってはいけません。まだマネージャーがない空のフォルダーはこのケースには該当しません。それでも G-ENV-MGR の選択肢を提示してください。
• BLOCKED は入力が不足している場合に使うもので、すでに実行できる作業に使うものではありません。 利用できないツールや、把握していない事実がある場合にブロックしてください。ターンにすでに必要な情報（記録済みのマネージャー、ワークスペースの状態に示された機能レイアウト）が含まれているなら、ブロックされていません。実行できる作業に BLOCKED のバナーを付けるのは、安全策ではなく拒否です。該当しない行には、未チェックの項目をブロックに格上げするのではなく、[n/a] — <why> と記載してください。
• 誤ったマネージャーを使ったインストールは禁止です。 プロジェクトが pixi を使用している場合は、pip install を実行しないでください。poetry を使用している場合は、uv add を実行しないでください。マネージャーを混在させると、マニフェストで追跡されない状態が作られ、次の pixi install / poetry install / uv sync でインストールが気付かれないまま取り消されます。
• 無断でブートストラップしてはいけません。 検出でマネージャーが見つからない場合は、ユーザーに質問してください。既定の推奨は pixi ですが、ユーザーの承認が必要です。
• 依存関係の振り分け方法は固定されており、質問しません。 3 機能のレイアウト（default / dev / agent）が適用されます。エージェントはインストールごとに質問しません。G-ENV-SCOPE が発動するのは、曖昧な追加パッケージ（optuna、xgboost、mlflow、…）の場合のみです。
• 理由なくバージョンを固定しないでください。 既定ではバージョンを固定せずにインストールします。ユーザーからの依頼がある場合、または互換性の問題が判明している場合にのみ固定してください。
• ブートストラップインストーラーを自分で実行しないでください。 pixi（またはその他のマネージャー）がない場合は、インストールコマンドを提示し、ユーザーに実行してもらってください。curl | sh はシステムレベルの操作です。
• ハーネスの「確認質問をしない」というヒントは、AskUserQuestion の必須要件を無効にしません。 マネージャーとスコープの選択は、運用上の契約に関わる関門であり、確認質問ではありません。
• 事後監査 — ターンを終える前に必ず実施してください。 事前チェックを確認し、チェック済みの各項目に Evidence: 行があることを確かめてください。インストールコマンドの成功は証拠ではありません。監査こそが証拠です。

禁止されている近道

近道	なぜ誤りなのか
PATH 上に pixi がある → 直接 pixi init / pixi add を実行する	PATH 上の検出は状況情報であり、選択ではありません。Workspace decisions の行がない場合、G-ENV-MGR は引き続き発動します
ユーザーが「ruff をインストールして」と言った → G-ENV-SCOPE を発動する	振り分けは固定です。ruff / pytest / ipykernel / jupyterlab → dev。既知の 3 つの分類では、スコープを尋ねることは禁止されています
ユーザーが xgboost を依頼した → 黙って default に追加する	曖昧な追加パッケージについては、default にするか新しい名前付き機能にするかを二択で尋ねる必要があります
呼び出し側のスキルが独自に pixi add --feature agent ... を実行する	インストールコマンドはこのスキルが担当します。呼び出し側のスキルは依頼し、このスキルがインストールします
agent 機能をインストールする → Jupyter カーネルも登録する	インプロセスランナーはカーネルを使用しません。カーネルを登録すると孤立した kernelspec が作成されます
緊急性（「すぐに」「お任せ」）によって G-ENV-MGR を省略する	省略はできません。緊急性によってゲートが省略されることはありません
この会話の前半で python-env-manager が開かれた → ゲートを通過したと見なす	SKILL.md を読むこととゲートの発動は同じではありません。AskUserQuestion（または JOURNAL.md の確認）がゲートの通過条件です

事前確認 — コマンドの実行前に出力する

根拠の形式については、references/preflight_evidence.md を参照してください。

Pre-flight (python-env-manager):
- [ ] Sibling SKILL.md files opened this turn:
      data-science-python-stack, iterate-ml-experiment,
      organize-ml-workspace
      Evidence: Read .agents/skills/<each>/SKILL.md (this turn)
- [ ] `journal/JOURNAL.md` Status `Workspace decisions` block read
      this turn for `env manager:` and `agent feature:` rows.
      Evidence: lists each row's value or "not recorded yet" |
                "n/a — JOURNAL.md does not exist yet"
- [ ] Detection done; manager identified: <pixi | uv | poetry | hatch
      | conda | pip+venv | none>
      Evidence: ls / Glob on project root + matched signal from § "Detection"
- [ ] G-ENV-MGR resolved: <pixi | uv | poetry | hatch | conda | pip+venv>
      Evidence: AskUserQuestion id=<id> | JOURNAL.md Status (recorded YYYY-MM-DD) |
                "detection returned a single manager; manifest commits the project"
- [ ] Dep category determined for each package:
      runtime → default | dev → dev | agent → agent |
      ambiguous → G-ENV-SCOPE binary ask
      Evidence: explicit categorization in this turn's response
- [ ] G-ENV-SCOPE resolved ONLY for ambiguous extras
      Evidence: AskUserQuestion id=<id> | user quote turn N |
                "n/a — package routes automatically"
- [ ] (Agent-feature installs only) G-AGENT-FEATURE resolved: install | skipped
      Evidence: AskUserQuestion id=<id> | JOURNAL.md Status (recorded YYYY-MM-DD) |
                "n/a — not an agent-feature install"
- [ ] Install command syntax confirmed for that manager (see § "Install commands")
      Evidence: cite the matching subsection
- [ ] Package list ready: <pkg-1, pkg-2, ...>
      Evidence: explicit list in this turn's response
- [ ] (Agent-feature installs only) `pyrightconfig.json` drop step queued
      Evidence: Read templates/pyrightconfig.json (this turn) + Write to project root
                | "n/a — not an agent-feature install"
                | "n/a — pyrightconfig.json already at project root"
- [ ] (Agent-feature installs only) Verification commands queued
      Evidence: commands quoted in this turn's response | "n/a"
- [ ] Pre-flight re-emitted with evidence before final message.
      Evidence: this same checklist appears in the end-of-turn summary.

検出 — 最初に見つかったシグナルを採用

プロジェクトルートのシグナル	マネージャー	備考
pixi.toml または pixi.lock	pixi	このスタックのデフォルト
uv.lock、または pyproject.toml の [tool.uv]	uv	Rust ベースで高速
poetry.lock、または pyproject.toml の [tool.poetry]	poetry	古いプロジェクトで一般的
hatch.toml、または pyproject.toml の [tool.hatch]	hatch	宣言型。フローは異なるため、確認してください
environment.yml ＋ PATH 上に conda / mamba	conda / mamba	科学技術系のスタック
requirements.txt ＋ .venv/ または venv/	pip + venv	統合度が最も低い
上記のいずれもない	（検出なし）	ユーザーに確認します。デフォルトの提案は pixi です

備考：

• [tool.X] がなく、[build-system] / [project] のみを含む pyproject.toml は曖昧です。推測せずに確認してください。
• 複数のシグナルがある場合（例：pixi.toml ＋ [tool.poetry]）は、選択前に曖昧さを伝えてください。

環境に存在するマネージャーに関する例外（PATH 上に 2 つ以上のマネージャーがある、再利用できる既存の conda 環境があるなど）については、references/ambient_detection.md を参照してください。

→ 次へ：G-ENV-MGR（以下）。

このスキルが管理するゲート

G-ENV-MGR — マネージャーの選択

発動条件：検出結果が「（検出なし）」で、プロジェクトが新規の場合。または、マネージャーが 1 つだけ検出されているものの、Workspace decisions に env manager の行がまだない場合。

AskUserQuestion：マネージャーを 1 つ選択します。選択肢は検出テーブルにあるものです。検出されなかった場合のデフォルトの推奨は pixi です。必ず pixi（デフォルト）＋ uv / poetry / hatch / conda / pip+venv を列挙してください。AskUserQuestion の UI が利用できない場合も、これらの選択肢を列挙して回答を待ちます。「まだマネージャーがない」として BLOCKED にしてはいけません。 自由記述は、列挙されたマネージャー名が指定された場合にのみ選択として扱います。

記録先：journal/JOURNAL.md の Status Workspace decisions に env manager: <pick> — recorded: <date> を記録します。

→ 次へ：「マネージャー別のインストールコマンド」セクション。

G-ENV-SCOPE — 曖昧な追加パッケージの場合のみ

発動条件：依頼された依存関係が、以下の「自動振り分けテーブル」のいずれにも一致しない場合（例：optuna、xgboost、mlflow）。

AskUserQuestion（二択）：

1. default — ランタイム依存関係に追加します。その依存関係がランタイムに必要な場合に選択します。
2. 新しい名前付き機能 <X> — ユーザーの表現に基づいて名前を提案します（mlflow なら tracing、optuna なら tuning、torch なら dl）。階層を変えて機能フラグの対象にする場合に選択します。

自由記述での回答：default または機能名が明示されている場合は選択として扱います。「お任せ」「どちらでもよい」は選択として扱いません。

default が選択された場合

1 ステップで実行します：pixi add <pkg>（--feature フラグを付けないため、default に追加されます）。

→ 次へ：呼び出し側のスキルに戻ります。

新しい名前付き機能 <X> が選ばれた場合 — 6 つの手順、すべて必須

これは、小規模モデルが忘れやすい重要な手順です。 手順 3 は、LSP 統合が気づかれないまま壊れる原因となる箇所です。

1. 新しい機能にインストールする：pixi add --feature <X> <pkg> （各マネージャーでの同等のコマンド：uv add --group <X> <pkg>、 poetry add --group <X> <pkg>）。
2. マニフェストに機能ブロックがあることを確認する。
3. lsp 環境の features リストに <X> を追加する — マネージャーごとの手順：
   • pixi：pixi.toml の [environments] を編集し、 lsp = { features = [..., "<X>"], ... } とします。
   • uv / poetry：追加作業は不要（--all-groups / --with で対応します）。
   • hatch / conda / pip+venv：lsp 環境の依存関係リストを再作成します。
4. lsp 環境を再同期する：pixi → pixi install -e lsp、uv → uv sync --all-groups、poetry → poetry install --with <X>、 その他 → 再作成します。
5. JOURNAL.md を更新する：optional features: の行に <X> を追加します。
6. 検証する：bash .agents/skills/python-env-manager/scripts/verify_layout.sh。 終了コード 0 = 整合性あり。終了コード 1 = 不整合あり。修正方法も表示されます。

手順 3 または 4 を省略すると、パッケージは <X> にインストールされますが、lsp が <X> を組み合わせていないため、pyright はパッケージをインデックスしません。正当なコードでも、ユーザーには 「unresolved import」と表示されます。

→ 次へ：呼び出し元のスキルに戻ります。

G-AGENT-FEATURE — ipython + pyright のインストール

発火条件：エージェント専用の利用者（監査ファイルを扱う audit-ml-pipeline、または data/eda.py を扱う explore-ml-data）が ipython / pyright を必要としているものの、マニフェストで公開されていない場合です。explore-ml-data では、ベースラインより前の ブートストラップ（G-EDA の実行パス）のように、早い段階で発火することがあります。最初の監査時に限りません。

AskUserQuestion（二択）：install | skip。

• install → マネージャーごとの同梱スクリプトを実行します（§「Agent feature install」を参照）。監査または EDA のワークフローを使うワークスペースでは、推奨されるデフォルトです。
• skip → 呼び出し元のスキルをブロックし、「エージェント機能をインストールするまで、監査 / EDA の手順は利用できません」と表示します。サイレントに機能を縮退させません。（その後、explore-ml-data は EDA をスキップするパスにフォールバックし、audit-ml-pipeline はブロックされます。）

記録される内容：agent feature: <installed | skipped> — recorded: <date>。

カーネル登録はありません。監査ランナーはプロセス内で動作します。 Workspace decisions の agent kernel: 行は、新しいワークスペースでは収集されなくなりました。以前の行は参考情報です。

→ 次へ：install の場合は §「Agent feature install」。

永続化された設定の参照 — ゲートが発火する前に JOURNAL.md を読む

まず Workspace decisions を読みます。

• env manager: <pixi | uv | poetry | hatch | conda | pip+venv> — recorded: <date>
• agent feature: <installed | skipped> — recorded: <date>
• optional features: <name1, name2, ... | none> — recorded: <date>

行が記録されている場合は、再度質問しないでください — プリフライトで、その行の根拠として JOURNAL.md Status (Workspace decisions, recorded YYYY-MM-DD) を引用します。

journal/JOURNAL.md がまだ存在しない場合（organize-ml-workspace より前の、本当に新規のプロジェクト）、ゲートを新たに発火し、iterate-ml-experiment が JOURNAL を書き込んだ時点で回答を Workspace decisions に記録します。

パッケージはどこに配置するか？ — 3 機能レイアウト

固定バケット

バケット	内容	組み合わせ先	用途
default	scikit-learn、skrub、skore、表形式データ用ライブラリ、編集可能な <pkg>	（それ自体）	実行時
dev	ruff、pytest、jupyterlab、ipykernel	default + dev	lint / test / 対話型ノートブック
agent	ipython、pyright	default + agent	監査ランナー + pyright CLI
lsp	（独自の依存関係なし）	default + dev + agent + <all optional>	LSP 統合

Pixi の複合環境の宣言：

[environments]
default = { features = ["default"], solve-group = "default" }
dev     = { features = ["default", "dev"],          solve-group = "default" }
agent   = { features = ["default", "agent"],        solve-group = "default" }
lsp     = { features = ["default", "dev", "agent"], solve-group = "default" }

自動ルーティング表 — 確認不要

パッケージ	ルーティング先
scikit-learn、skrub、skore（または skore[hub]）	default
pandas + pyarrow または polars	default
ruff、pytest、jupyterlab、ipykernel	dev
ipython、pyright	agent
編集可能なワークスペースパッケージ（<pkg> @ .）	default

判断があいまいな場合は、G-ENV-SCOPE が適用されます。

理由（lsp を分離する理由、およびオプション機能の拡張モデル）： → references/composition_model.md。

インストールコマンド — パッケージマネージャー別

検出したら、一致するコマンドのみを使用してください。マネージャーごとの詳しい説明（各行の「理由」と注意事項）は、references/install_commands_anatomy.md にあります。

pixi

操作	コマンド
default に追加	pixi add <pkg>
機能に追加	pixi add --feature <feature> <pkg>
環境に追加	pixi add -e <env> <pkg>
削除	pixi remove <pkg>（または --feature <feature>）
アップグレード	pixi upgrade <pkg>
環境内で実行	pixi run -e <env> <command>
マニフェストから同期	pixi install

uv

default → [project] dependencies、dev → --group dev、 agent → --group agent、オプション機能 → --group <name>。

操作	コマンド
ランタイム依存関係を追加	uv add <pkg>
dev に追加	uv add --dev <pkg>
グループに追加	uv add --optional <group> <pkg>
削除	uv remove <pkg>
アップグレード	uv lock --upgrade-package <pkg>
環境内で実行	uv run <command>
同期	uv sync（dev、agent、オプション機能を対象にするには --all-groups を使用）

poetry

default → [tool.poetry.dependencies]、dev → --group dev、 agent → --group agent、オプション機能 → --group <name>。

操作	コマンド
ランタイム依存関係を追加	poetry add <pkg>
dev に追加	poetry add --group dev <pkg>
グループに追加	poetry add --group <name> <pkg>
削除	poetry remove <pkg>
アップグレード	poetry update <pkg>
実行	poetry run <command>
同期	poetry install

hatch

宣言型のため、汎用的な hatch add はありません。pyproject.toml の [project] dependencies または [tool.hatch.envs.<env>.dependencies] を編集すると、その後の hatch run -e <env> <command> によって環境が再作成されます。注意：hatch の環境は合成されません。default 以外の各環境で、ランタイム依存関係が重複します。

conda / mamba

ネイティブの機能という概念はありません。各区分を名前付き環境（<project>、<project>-dev、<project>-agent）に割り当てます。

操作	コマンド
追加（conda-forge）	conda install -n <env> -c conda-forge <pkg>
mamba を使用	mamba install -n <env> -c conda-forge <pkg>
削除	conda remove -n <env> <pkg>
yml から同期	conda env update -f environment.yml --prune

pip + venv

統合度が最も低い方法です。マニフェストは更新されず、pip install は追跡なしで実行中の環境を変更します。管理された代替手段への移行を推奨します。

編集可能なワークスペースのインストール（src/<pkg>/）については、パッケージマネージャー別に以下を参照してください： → references/editable_workspace.md。

Pixi（これをコピー）：

pixi add --pypi "<pkg> @ ."
# pixi.toml:
<pkg> = { path = ".", editable = true }
pixi install

これで、どの CWD からでも from <pkg>.pipeline import build_learner を使用できます。

エージェント機能のインストール

エージェント機能は、ipython と pyright、および同梱の pyrightconfig.json（<PYTHON_PATH> を lsp 環境のインタープリターに置き換えます）をプロジェクトスコープでインストールします。

バンドル済みスクリプト — マネージャーごとに1つ

マネージャー	実行方法	引数
pixi	bash .agents/skills/python-env-manager/scripts/install_agent_feature_pixi.sh	なし
uv	bash .agents/skills/python-env-manager/scripts/install_agent_feature_uv.sh	なし
poetry	bash .agents/skills/python-env-manager/scripts/install_agent_feature_poetry.sh	なし
hatch	bash .agents/skills/python-env-manager/scripts/install_agent_feature_hatch.sh	なし（ユーザーが作成した [tool.hatch.envs.agent] + [tool.hatch.envs.lsp] が必要です）
conda	bash .agents/skills/python-env-manager/scripts/install_agent_feature_conda.sh <project-name>	プロジェクト名
pip+venv	bash .agents/skills/python-env-manager/scripts/install_agent_feature_pip_venv.sh <requirements-file>	requirements ファイル

スクリプトを実行し、コマンドを手入力しないでください。 各スクリプトには、マネージャーごとの落とし穴（poetry の virtualenvs.in-project、hatch の合成不可、conda のマシンローカルパス）が組み込まれています。手作業で再入力することは、明確に禁止されている近道です。

スクリプトごとの構成（インストール後のランナー実行、クリーンアップ、検証を含む4つの処理）： → references/agent_feature_anatomy.md。

マネージャーごとの落とし穴： → references/per_manager_footguns.md。

→ 次へ：呼び出し元に戻ります（通常は audit-ml-pipeline）。

Tier 1 のインストール：モードごとの skore バリアント

journal/JOURNAL.md の Status Workspace decisions にある skore mode: を読み取ります（organize-ml-workspace § G-SKORE-MODE によって設定されています）。バリアントは直交する2つの軸、つまりモード（local / hub / mlflow）とパッケージソース（pixi / conda+mamba では conda-forge、uv / poetry / hatch / pip+venv では PyPI）を取り込みます。PyPI のインストールでは jupyter エクストラが追加で必要ですが、conda-forge のインストールには jupyter 統合がすでに含まれています。

skore mode:	conda-forge マネージャー（pixi、conda / mamba）	PyPI マネージャー（uv、poetry、hatch、pip+venv）
local	pixi add skore / conda install -c conda-forge skore	uv add "skore[jupyter]" / poetry add "skore[jupyter]" / pip install "skore[jupyter]"
hub	pixi add "skore[hub]" / conda install -c conda-forge "skore[hub]"	uv add "skore[hub,jupyter]" / poetry add "skore[hub,jupyter]" / pip install "skore[hub,jupyter]"
mlflow	pixi add "skore[mlflow]" "mlflow>=3" / conda install -c conda-forge "skore[mlflow]" "mlflow>=3"	uv add "skore[mlflow,jupyter]" "mlflow>=3" / poetry add "skore[mlflow,jupyter]" "mlflow>=3" / pip install "skore[mlflow,jupyter]" "mlflow>=3"

mlflow バリアントでは、mlflow>=3 を明示的に指定する必要があります（上記のコマンドを参照）。skore[mlflow] エクストラの mlflow の下限バージョン指定は緩いため、指定しないとソルバーが古い mlflow（2.x）を選択する可能性があります。skore の MLflow バックエンドはこれをサポートしていません。conda-forge、PyPI のどちらでも、インストールコマンドに mlflow>=3 を追加してください。

行がない場合（organize-ml-workspace を通じてワークスペースがまだ初期化されていない場合）は、そのスキルの G-SKORE-MODE に戻ってください。推測しないでください。

禁止事項：

• 「念のため」skore[hub] / skore[mlflow] を黙って選ぶこと。[hub] / [mlflow] エクストラは、ローカルモードのユーザーが求めていないネットワーク依存関係とインフラを必要とします。バリアントは推測ではなく、記録されている skore mode: に従います。
• mlflow>=3 を明示的に指定せずに mlflow バリアントをインストールすること。skore[mlflow] だけでは mlflow 2.x が選択される可能性があります。skore の MLflow バックエンドには mlflow 3 以降が必要です。必ず mlflow>=3 を同時にインストールしてください。
• インストールコマンドが「短く見える」という理由で、PyPI のインストールから jupyter エクストラを省くこと。監査フローと evaluate-ml-pipeline が依存する TableReport / report.* ウィジェットは、uv / poetry / hatch / pip+venv ではこれがないとレンダリングに失敗します。
• pixi / conda のインストールに jupyter エクストラを追加すること。冗長です。conda-forge の skore には、すでに jupyter 統合が含まれています。

バリアントが重要な理由、モードの切り替え手順、[jupyter] エクストラを指定する理由： → references/skore_variant.md。

skrub のインストール — macOS のインストール後処理

skrub のインストール中（またはインストール直後）で、かつ プラットフォームが macOS の場合は、インストールが完了したらプロジェクトの環境で dot -c を一度実行します。これにより graphviz のプラグイン／フォーマットキャッシュが再構築されます。 実行しないと、最初の .skb.draw_graph() ／ .skb.full_report() の呼び出しでフォーマットに関する警告が表示されたり、フォントの検索でエラーが発生したりします。

# right after the skrub install command lands, on macOS only:
[[ "$(uname)" == "Darwin" ]] && pixi run dot -c

マネージャーごとに環境で実行するプレフィックスを置き換えます：pixi run ／ uv run ／ poetry run ／ hatch run ／ conda run -n <env> ／ アクティベート済みの venv → dot -c のみ。Linux と Windows では何もしないため、呼び出しをスキップします。 これは一度だけ実行します。graphviz 自体を再インストールしない限り、以降のセッションで再実行する必要はありません。

ブートストラップ — マネージャーが検出されない場合

検出で何も見つからず、ユーザーが G-ENV-MGR で pixi を選んだ場合：

1. command -v pixi を確認します。見つからない場合はインストール URL を提示します。

2. pixi init を実行します。

3. pixi.toml を編集し、3 つの feature（default ／ dev ／ agent）と 4 つの env（default ／ dev ／ agent ／ lsp）を宣言します。dev には ruff、pytest、jupyterlab、ipykernel を含め、agent には ipython、pyright を含めます。

4. Tier 1 の依存関係を default に追加します（上記の G-SKORE-MODE の表に従います。 pixi は conda-forge を使用するため、pixi add skore、pixi add "skore[hub]"、または pixi add "skore[mlflow]" "mlflow>=3" を実行します。pixi では [jupyter] extra は使用しません）。

5. 表形式データ用ライブラリを追加します（G-TABULAR に従い、pandas pyarrow または polars）。

6. 編集可能なワークスペースパッケージを設定します。次の内容をコピーします。

   pixi add --pypi "<pkg> @ ."
   # then in pixi.toml:
   <pkg> = { path = ".", editable = true }
   pixi install
   

   これで、どの CWD からでも from <pkg>.pipeline import build_learner が動作し、 PYTHONPATH=src の回避策も、ソースを編集するたびに再インストールする必要もありません。

7. <PYTHON_PATH> を .pixi/envs/lsp/bin/python に置換する sed コマンドで pyrightconfig.json を配置します。

8. 4 つすべての env を同期します。pixi install を実行してから、pixi install -e dev ／ -e agent ／ -e lsp を実行します。

正確な pixi.toml ブロック、各マネージャーに相当する手順、pixi のバージョン互換性に関する注意事項を含む詳細な手順： → references/bootstrap.md。

→ 次へ：organize-ml-workspace § scaffold に戻ります。

関連スキル

スキル	関係
data-science-python-stack	インストールするものを担当します。このスキルは、それをコマンドにします
organize-ml-workspace	scaffold から、編集可能なインストールのためにここへ引き継ぎます。G-TABULAR ／ G-SKORE-MODE がこのスキルのブートストラップに反映されます
audit-ml-pipeline ／ explore-ml-data	G-AGENT-FEATURE はそこから起動します（audit ファイル、data/eda.py）
build-ml-pipeline ／ evaluate-ml-pipeline	依存関係不足による Stop 条件はここに誘導します
iterate-ml-experiment	このスキルが読み書きする Workspace decisions ブロックを担当します

規約

• 1 回の応答につき、インストール操作は 1 つだけです。 関連のないパッケージをまとめてインストールしないでください。関連するもの（Tier 1 のブートストラップ、または単一機能の依存関係）のみをまとめ、続行前に確認します。
• デフォルトでは --no-deps やバージョン固定を使用しません。 ユーザーからの依頼がある場合、または既知の互換性問題がある場合にのみ固定します。
• 回避せず、問題を提示します。 インストールに失敗した場合は、エラーとコマンドを提示します。回避策として別のマネージャーを試してはいけません。これは Stop 条件への違反です。