【Python】自作ライブラリを別プロジェクトから使う：editable installの始め方

PythonのTopに戻る

自作の共通関数を別プロジェクトから使うなら、小さなパッケージにしてeditable installする方法がある。開発中はソースの修正を反映しやすく、利用側へ毎回.pyをコピーする必要がなくなる。ただし、開発用インストールで動くことと、配布物を通常インストールして動くことは別である。最後に通常インストールでも確認しよう。

srcの下へパッケージを置く

ここではlocal-toolsというフォルダーにpyproject.tomlを置き、その下のsrc/tip_shared/__init__.pyへ関数を保存する。tip_sharedがimport名、tip-shared-demoが配布名である。名前が違っていても問題はないが、どちらをどこで使うかは区別しておく。

srcを間に置く構成にすると、プロジェクトのルートから起動しただけで偶然ソースが見える状態を避けやすい。利用側でimportできるかを確かめる際も、ソースの隣からだけではなく、別の作業フォルダーから確認するとよい。

最小限のビルド設定と関数を用意する

local-tools/pyproject.toml

[build-system]
requires = ["setuptools>=68"]
build-backend = "setuptools.build_meta"

[project]
name = "tip-shared-demo"
version = "0.1.0"

[tool.setuptools.packages.find]
where = ["src"]

local-tools/src/tip_shared/__init__.py

def scale(value):
    return value * 2

build-systemはビルド時に必要な道具、projectは配布物の名前や版を示す。この例は標準ライブラリ以外の実行時依存を持たない。実際に外部ライブラリを必要とするなら、実行時のdependenciesも適切に宣言する。

利用側のvenvへ開発用インストールする

次は利用側プロジェクトのフォルダーで実行する書式である。隣のlocal-toolsを指す相対パスは、自分の配置に合わせる。使用するPythonを明示すれば、別環境へ入れてしまうことを減らせる。

インストール例：Linux/macOSとWindows PowerShell（Windows/macOS未実行）

# Linux/macOS：利用側プロジェクトで実行
.venv/bin/python -m pip install -e ../local-tools
.venv/bin/python -c "from tip_shared import scale; print(scale(3))"

# Windows PowerShell
& ".\.venv\Scripts\python.exe" -m pip install -e ..\local-tools
& ".\.venv\Scripts\python.exe" -c "from tip_shared import scale; print(scale(3))"

通常、ビルドに必要な依存はpipが分離した環境へ用意する。この記事の動作確認ではネットワークを使わないよう、既存のsetuptools 84.0.0を使った限定的なビルド手順で検証した。–no-build-isolationを日常の標準手順として追加する必要はない。

修正の反映と通常インストールを比較する

最初の関数は入力を2倍にする。開発用に導入した後、ソースの2を3へ変えて新しいPythonプロセスから呼ぶと、結果は6から9へ変わる。同じ変更前のwheelを通常インストールした別環境では、結果は6のままである。

実行結果

Editable before: 6
Editable after: 9
Regular wheel: 6

editable installは、基本的には開発元を参照できるように環境へ情報を登録する仕組みである。すでにimport済みの関数が、ファイル編集と同時に自動で差し替わるわけではない。ノートブックなどの長く動くプロセスでは再起動して確認する方が確実である。

編集後に再インストールが必要な場合

Pythonコードの単純な変更は反映されやすいが、配布メタデータ、依存関係、コマンド入口などの変更は再インストールが必要になる。C拡張などのコンパイルされた部分も、ソースを編集するだけでは新しいバイナリにならない。何が即時に変わるかはビルドバックエンドにも依存する。

editableの環境をそのまま別PCへコピーしても、参照元のソースが存在しなければ使えない。環境を再構築するときは、ソースの版と配置を用意し、その環境で改めてインストールする。開発用の絶対パスをrequirementsへ記録していないかにも注意したい。

通常インストールを最後の確認に使う

開発が一区切り付いたら、wheelなどの配布物を作り、新しいvenvで通常インストールして確認する。これにより、srcにはあるが配布物へ入っていないモジュールや、同梱データの不足を見つけやすくなる。利用側の代表的な処理を、ソースと離れた場所から動かしてみよう。

同梱データを読む処理にはimportlib.resourcesを使い、利用者の入力ファイルは外からパスを受け取るようにすると、配置の違いを減らせる。開発用と通常用の両方で同じ関数が動くことを確認すれば、共通処理を他の解析へ渡す際も判断しやすい。

この例はローカルでの再利用までを扱う。公開レジストリへのアップロードは不要であり、試しに同名のパッケージを外部から導入する必要もない。共有する相手が増えた段階で、配布元や版の管理方法を別途決めればよい。

動作確認と参考資料

掲載例はLinux・CPython 3.12.14で動作確認した。OS固有のコマンドや環境ごとに変わるパスは、本文中の条件を確認して使ってほしい。

関連するTips

PythonのTopに戻る