Python 開発環境作成テンプレート
ちょっとした機能をササッと作れるPythonですが、調子に乗って新しい機能を作り続けていくと開発環境が肥大化して管理が難しくなってきます。
特に仕事で他の人と共有するだとか、GitHubに上げて誰かに見られる前提にするとかの場合には最小限のモジュール構成にするべきですが、複数プロジェクトで共有の環境を用いていると、どのプロジェクトでどのモジュールを使っているかが分からなくなってきますね。
そうならないためにも、プロジェクト作成の段階で開発環境を分けておこう、そのテンプレートを作っておこう、という記事です。
想定環境
Windows
Python >= 3.3
pip
Windowsを想定していますが、他OSで共通するところなどあるか分かりません。悪しからず。
仮想環境
そもそもPythonが外部から得たモジュールをどこにインストールし、参照しているか。それはPythonのインストールディレクトリにあるsiteディレクトリ、"site-packages"になります。
siteモジュールを使うことでその位置は確認できます。
site-packagesの場所を確認する
デフォルトではモジュールはこのディレクトリへインストールするため、プロジェクトが多数あれば肥大化しますし、「このプロジェクトではあのモジュールはver.xx.yyがほしいのにいつの間にかバージョンアップしてる」などが発生します。
さて、Pythonにはver.3.3からvenvが追加されました。ドキュメントにも書かれていますが、これは前述のsiteディレクトリをシステム共通のディレクトリから切り離すことで、プロジェクトごとに独立したパッケージ群を管理するための機能です。
| デフォルト環境でのモジュール管理 | 仮想環境でのモジュール管理 |
|---|---|
 |
 |
セットアップ
仮想環境の作成
Python(>=3.3以降）をインストールしておきます。
（インストーラをダウンロードして実行するだけなので割愛）
コマンドライン(cmdやpower-shell)から好きなディレクトリに移動し、venvを実行します。
python -m venv app_env
pythonのバージョンを指定する場合は、これにあわせてください。
たとえばpython 3.10.xを使うなら以下のようにし、この場合には仮想環境はPython 3.10.x用の環境が作られます。
py -3.10 -m venv app_env
これにより、カレントディレクトリに"app_env"というディレクトリが作成され、その中に仮想環境がセットアップされます。
コマンド中の"app_env"を変えればその通りにディレクトリ名が変えられるので、好みやプロジェクトの意向に合わせましょう。私の場合はだいたい"env"にしますし、1プロジェクトで複数バージョンのPythonを使いたい場合には"env_3.10"などバージョン名を追加することもあります。
モジュールのインストール
作成した仮想環境に必要なモジュールをインストールしていきます。
インストール自体に特別なコマンドは必要ありませんが、「今から作業するのはこの仮想環境に対してですよ」という指定が必要です。
作成した仮想環境のディレクトリ(以降、"app_env")に、そのためのモジュールファイルapp_env/Scripts/activateがあります。MS-DOS用のactivate.batやPowerShell用のactivate.ps1がありますので、必要に応じて実行してください。コマンドプロンプト上で作業しているなら、以下コマンドで実行できます。
call app_env\Scripts\activate
コマンドプロンプト上の表示が以下のように変わったら成功です。
(ディレクトリは適宜読み替えてくださいね)
(app_env) D:\develop\app>
この状態でモジュールインストールを行えば、仮想環境へのモジュールインストールができます。
ここではpipを用いますが、この仮想環境ではpip自体も初期状態となるので、先に更新を行った方がいいでしょう。
python -m pip install --upgrade pip
ちなみに、この仮想環境下にいる限りは、pythonのバージョンは仮想環境作成時のバージョンに従うため、実行時にバージョンを指定する必要はありません。逆に言えば、他バージョンのpythonの実行はできません。（できるかもしれませんが、面倒そうです）
あとは好きなモジュールをインストールしていきましょう。
セットアップが終わったら、deactivateを実行することで仮想環境から抜け出します。
deactivateは先程実行したactivateの中で定義されているため、仮想環境が有効な時にのみ実行可能な処理になります。
call deactivate
もちろん、コマンドライン自体を終了しても問題ないでしょうけど、手癖にしておいた方がいいかと思います。
仮想環境下での実行
ここまでで、仮想環境のセットアップができました。
ですがセットアップした環境も使わなければ意味がありません。
ある仮想環境を用いて開発されたpythonモジュールを実行するためには、当然その仮想環境を有効化しておく必要があります。
難しいことではありません。セットアップ時と同じく、仮想環境を有効にした上で実行するだけです。
call app_env\Scripts\activate
python xxxxxxxx.py
call deactivate
インストーラーのテンプレート化
venvで仮想環境を作成するメリットの一つは、誰かと環境を共有することが容易になることです。仮想環境を前提とすることで、Python開発環境のインストーラーを作成しやすくなります。
まずは、仮想環境にインストールされたモジュールの一覧を出力します。これにはpip freezeを用います。当然ですが、仮想環境は有効化しておきましょう。
python -m pip freeze > requirements.txt
これにより、カレントディレクトリにrequirements.txtというファイルが作成され、その中には仮想環境にインストールされたモジュール名とバージョンが記載されています。ファイル名は任意ですが、よくrequirements.txtが用いられるようです。
さて、以下にインストーラーファイルのテンプレートを記します。
@setlocal
@pushd %~dp0
@rem Pythonのバージョン
@set PY_VERSION=3.10
@rem 仮想環境のディレクトリ名
@set VENV_DIR=app_env
py -%PY_VERSION% -m venv %VENV_DIR%
call %VENV_DIR%\Scripts\activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
call deactivate
@popd
@endlocal
@exit /b 0
このようにして作ったインストーラーファイルと、必要な他ファイル(requirements.txtなど)を置き、READMEにでも書いておけば、開発環境を共有する相手にも分かりやすいでしょう。
ちなみに、pipで自動ダウンロード/インストールができないモジュールもあります。PyTorchの旧バージョンなどもそうですね。
この場合はpip freezeしてもrequirements.txtには出力されませんし、されてもインストールすることができません。途中でエラーで落ちるのが関の山です。
やりようとしては、インストーラーファイル内でダウンロード処理を書く、あるいはREADMEファイルなどでダウンロードページを案内するなどして指定のディレクトリに*.whlファイルを用意させ、これからpip installを用いてインストールさせるといいでしょう。
*.whlファイルの配布が終了されることを考えると怖いですが、まあ本当は最新の安定版で動作するようにメンテナンスするべきなんでしょうね。どうしてもと言うのであれば、自分のPCや会社のサーバーに置いておき、インストーラーに含めるといいかもしれませんね。公開中のGitHubにファイルを上げるのは、良し悪し判断がつきません。
さいごに
記事に誤りや、こうした方がいいよと言ったアドバイス等あれば、コメントいただければと思います。がんばります。
Discussion