たまにはゲーム以外の話もしようということで、Pythonの環境の話をしようと思います。
色々やるときに便利なPython仮想環境について今回は話をしようと思います。
仮想環境そのものの話についてはあんまり詳しく説明はしません。
1. なぜPipenvか
condaとかdockerとか最近では色々選択肢があります。
というか、許されるならdockerでまとめとくのが一番楽な感じがする…。
それでも、業務との絡みでpipenvそこそこ使えた方が良いよねという観点で今回は筆を執っています。
比較的消極的な理由ですがあるあるなので、説明したいと思います。
1.1. 使用環境
業務では色んな環境で使用しますので、その中でリテラシ最低レベルに合わせないと組織内で頒布出来ない…ということで
| 項目 | 要素名 | 説明 |
|---|---|---|
| OS | Windows10(64bit) Native | 企業あるあるです。はよ11使わせてくれ。できればWSL2も使わてくれ。 |
| Python | Python for Windows | 当然環境にあったPythonを使用します。NCCLなどの分散学習向けの頻出ライブラリが使えません。 |
| IDE | Visual Studio Code | これは許されている。人権がある。 |
この上「実行ファイルをくれ」とか言われて工数が少ないのでPyInstallerとか使うと「重い!」ってキレられる世界です。
1.2. 商用利用での注意点
pipenv + .venv 環境については商用利用についての制限がありません。
これはWebで利用者が良くわからないが動く手順を探してきて動かしてもうっかりライセンス違反にならないという点では重要です。
Python界隈ではconda(miniconda)やdockerが比較的人気でエコシステムも含め素晴らしいと思ってはいるのですが。
2022/07/21現在確認している範囲では以下の様になっています。
conda : デフォルトのAnacondaリポジトリの商用利用に要ライセンス。Anacondaリポジトリを外して運用する分には無料での商用利用が可能。
docker : docker-desktopが商用利用に要ライセンス。docker engineだけならOKっぽいがWindowsで普通にdocker入れるとdocker-desktop入っちゃう。
こういう状況なので、お上が気持ちよく全社向けライセンス取ってくれる分にはなんの問題も無いんですが、そうでない場合はメンドクサイ稟議を通さないといけなくなるわけです。
受ける側が「退職まで凌げればそれでいい」とか思ってる場合はなおさら通らないですね。
それでも「ライセンス違反はするな」って管理の負担は押し付けられるわけなので(その一方で「仮想環境とか使えば一発でしょ?」とか言ってくる人もいるけど)、対策を兼ねて現状ライセンスで問題が無く、一応公式推しのPipenvを使っているわけです。
conda-forgeとかが安定してきたらそっちに移住とかでも良いんですが、会社あるあるで「一度定住すると腰が重くてみんな移行しない」ということになるので現状安定しているということからPipenv選んでます。
2. 先に言ってよ～
そこそこ運用してきているんですが「先に言ってよ～」ポイントが結構あったので
2.1. 環境変数の設定
とりあえずこれ。
PIPENV_VENV_IN_PROJECT を 1 にする。
値はtrueとかでもよかったと思う。
参考サイト
これをやっておくと、pipenvを実行したディレクトリに仮想環境ディレクトリの.venvができる。
これをやらないと、デフォルトではどの環境でもユーザーのディレクトリの下に謎のハッシュキーつきの仮想環境ディレクトリが作成され、後で消して作り直したいときなどに探すが面倒of面倒。
2.2. PowerShellのExecution Policy Settingsの変更
作成した仮想環境をactivate(有効化)するには、.venvのあるところで
python -m pipenv shell
とかすれば良いのですが、コンソールに環境名表示が無かったりして不親切です。activateされてるかどうか良くわからん。
これに対しては最近のWindows環境(PowerShellが使える環境)では、.venv/Scripts/Activate.ps1を実行してやると良いです。
しかし、デフォルトではセキュリティ設定の関係上このスクリプトは実行できません。
ということで、こいつを設定してやります。↓参考サイト stackoverflow.com
Set-ExecutionPolicy Unrestricted -Scope Process
なんか聞かれますがYesかAllで通してください。
Visual Studio CodeなどのIDEはPython仮想環境を選択している場合は(デフォルトではプロジェクトディレクトリ直下の.venvは優先的に見に行く)、
選択されている仮想環境のActivate.ps1をターミナル起動時に自動実行してくれるのでちょっと楽です。
既に開いているターミナルおよびその復帰には適用されないので既存のターミナルは一旦閉じてください。
2.3. Pipenvで上手く入らないパッケージがある
PyPIでないリポジトリから持ってくるケース等はPipenvで上手くパッケージをインストールできないケースがあります。
個人的な代表格がPytorch(個人的に良く使うので…この辺はどれが代表格かは人による)。
インストールページが吐いてきたpipのところをpython -m pipenvに置き換えても途中でこける。
この場合は仕方ないので、activateした仮想環境下でpipを使って入れています。
これやっちゃうとPipenvの管理ファイルであるPipfileに反映されなくなっちゃうのでバージョン管理の観点からは利点が結構削られてしまうのですが、まぁ入らないものは入らないでしょうがない。
ということで、入れるパッケージについてはpip freezeとかでrequirements.txtとかを出力させて管理しています。
まぁ、誰も作業してくれなくて自分がやることが多いんですけどね。
2.4. 環境の削除
基本的には.venv以下が環境の本体なのでこれを消せばOK。
あとついでに、Pipfile, Pipfile.lock, requirements.txtを消しておく。
これらがあると、pipenvが気を利かせて、これらに書かれている環境で構築を始めてしまうので、作り直したい際は必ずこれらは消しておくこと。
(もしくは読まれないようにRename)