<aside> 🪄

Pixi Advent Calendar 2025 4日目の記事です。

</aside>

conda の話が続いたので閑話休題として pip で入る PyPI package の話をします.

Pixi で Python プロジェクトを管理する

3日までずっと pixi global の話をしていて気づいたら conda package までビルドしてしまいましたが, project local の依存関係を管理するのが本来の使い方です. 詳細は↓をご覧ください

Basic Usage - Pixi by prefix.dev

Pixiはプロジェクトを作成する際は、メタデータ定義ファイルのフォーマットを pixi.tomlpyproject.toml から選択します。

pixi add で project local で使用する python を指定/インストールし, 一瞬で依存関係に追加することができます。

$ pixi init
$ pixi add python==3.13
[workspace]
authors = ["denkiwakame <>"]
channels = ["conda-forge"]
description = "Add a short description here"
name = "cpp-project"
platforms = ["linux-64"]
version = "0.1.0"

[tasks]

[dependencies]
python = "==3.13"

pixi.toml の内容は pyproject.toml では [tool.pixi] 名前空間に展開されます →

$ pixi init --format pyproject
$ pixi add python==3.13
[workspace]
authors = [{name = "denkiwakame", email = ""}]
dependencies = []
description = "Add a short description here"
name = "pixi-faiss-gpu"
requires-python = ">= 3.11"
version = "0.1.0"

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling"]

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["linux-64"]

[tool.pixi.pypi-dependencies]
my-python-module = { path = ".", editable = true }

[tool.pixi.tasks]

[tool.pixi.dependencies]
python = "==3.13"

<aside> 👼🏻

最終的に python package になるなら pyproject それ以外は pixi.toml を選択します

</aside>

$HOME/.pixi # pixi global のツールが入るところ
$HOME
  |- project 1 # C++/Rustプロジェクト
       |- pixi.toml  # pixi メタデータ
       |- .pixi/envs # プロジェクト毎の仮想環境の所在地
  |- project 2 # Pythonプロジェクト
       |- pyproject.toml # pixi メタデータ
       |- .pixi/envs

Pixi では PyPI package も管理できる

pixi は基本的には conda package manager ですが, pip package を管理することができます. conda | pypi で一覧できるので, それぞれのライブラリが何経由で入ってきたかを一望できますね.

<aside> 👼🏻

研究では PyPI package を第一に選択し, 非言語依存/ツールなど足りない部分を conda packageで補う使い方をしています.

</aside>

my-project % pixi add --pypi ruff
✔ Added ruff >=0.8.1, <0.9
Added these as pypi-dependencies.

my-project % pixi list
python                       3.12.7     hc5c86c4_0_cpython            30.1 MiB   conda  python-3.12.7-hc5c86c4_0_cpython.conda
python_abi                   3.12       5_cp312                       6.1 KiB    conda  python_abi-3.12-5_cp312.conda
readline                     8.2        h8228510_1                    274.9 KiB  conda  readline-8.2-h8228510_1.conda
ruff                         0.8.1                                    30 MiB     pypi   ruff-0.8.1-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

経緯としては, pixi は当初内製で PyPI resolver rip を開発していたのですが, より優れた uv を取り入れ, rip を R.I.P ──── いや何を言っているんだ───捨てる決断をしたのです. この決断は私の pixi コミュニティへの信頼を非常に高める結果となりました.

彼らは最良のシステムを作り上げるためなら外部からベストなものを躊躇なく取り入れていくと宣言したのです. package manager 戦争で○年後 uv が下剋上されても, pixi は backend library をすげ替えるだけなので, 新しい pip package manager の usage を覚え直す必要はないということです.

Adopting uv in pixi

conda package と PyPI package, 混ぜていいの!?

いや駄目に決まってるでしょう, 何を言っているんですか. conda-forge と pypi は本来一神教です.

<aside> 👼🏻

PyPI package を管理するときは, Python package は PyPI, 非Python package は conda で管理するなどの基準を設け, 低レイヤの依存 package を混ぜないで下さい.

<aside> 📖

  1. conda と PyPI を、低き層の依存にて結びつけてはならない. ちなみに同名の package を入れた場合は conda が優先される

  2. 大いなる依存(C/C++/低レイヤライブラリ)は conda に委ね 清き Python(pure-python)を PyPI に委ねよ

  3. 汝が py | nanobind の技を用いるなら 石材(build deps)のみ conda に求め 造りたる artifact は PyPI の器に授けてもよい

  4. 境界を乱す者には

    solver conflict の雷、 ABI Mismatch の地割れ、 glibc version の荒ぶる風 が襲いかかるであろう

</aside>

</aside>