Pythonインストール（venv）

• Windows 10
• Python3.3以降

以下にいろいろ書いているが、まず使ってみないことには利点もわかりづらいため、まずは公式インストーラで普通にインストールすればよいと思う。

• Welcome to Python.org

各ツールが何者で、何故必要なのかは、以下の記事が参考になるかも。

• 4.3. pip - ゼロから学ぶ Python
• 4.4. venv - ゼロから学ぶ Python
• 4.5. pipenv - ゼロから学ぶ Python
• 4.6. poetry - ゼロから学ぶ Python

もう少し詳しい歴史的背景

• pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator

Pythonは、少し環境構築の方法を検索するとインストールにも様々なツールがあることがわかり、 一方の記事で賞賛されていたものが他の記事では貶されたりしていて、何から手を付けてよいかわからなくなる。

• pyenv、pyenv-virtualenv、venv、Anaconda、Pipenv。私はPipenvを使う。 - Qiita
• The Big List of Python Packaging and Distribution Tools

これらのツールは、大別して主に2つの機能を提供する。

• Python本体バージョンの分離・切り替え
• パッケージ環境の分離・切り替え

要は、「Python3.7、入ってるライブラリはNumpy1.17と○○と○○」「Python3.9、入ってるライブラリはNumpy1.19と○○」みたいな環境が独立してPC内に共存していて、 実行したいスクリプトをどの環境で動かすか、選べるようにしておくのがよいということ。

中長期的な使用を見据えると、パッケージ環境の分離はなるべく行った方がよい。

• 長く使っていると、古いコードが後方互換性により動かなくなったりする
  • Python本体の後方互換性はあまり崩れることは無いが、パッケージはたまに崩れることがある
  • →古いバージョンの環境を残しておくと、古いコードでも動かせる状態を保てる
• 多くのパッケージをインストールしていると、依存関係の問題が発生しやすくなる
  • あるパッケージを入れたらNumPyのバージョンが下がり、それにより他のプログラムの挙動がおかしくなった、など
  • →プロジェクトごとに、なるべくそれで使う必要最小限のパッケージを入れた環境で行った方がよい

環境分離ツールを使うとそれがやりやすくなるので、インストール前にどれを使うか選ぶことになる。

Pythonの実行環境というより、OS環境をまるごと分離する。
環境分離とはいってももう一段上のレイヤーの話となる。

ある程度の規模のプロジェクトで、Python以外にもデータベースや他のツールを組み合わせて1つのシステム全体を作るなら、 先ほどの議論が当然他のツールにも当てはまるので、こちらの方が理想的ではある。

また、もともとPythonはLinuxと相性がいいので、Windowsで使う際、特有のエラーが発生することがある（デフォルト文字コードの違いをライブラリが考慮しきれてなかったなどわかりやすい原因もあるが、よくわからないのもたまに発生する）。 なのでそういう意味でも、特にWindowsではLinuxの仮想環境を作ってそこで動かすというのも有効な手となる。

Docker Desktop for Windows と WSL2 を組み合わせて使えば、Linux上でも複数環境を共存できる。最近ではこの組み合わせが比較的、記事も出てきやすい。
更にその上で下記のツールを使えば、WSL上でも複数の環境を共存させることもできる。

ただし、機械学習などでWSLからGPUを使うことに関しては、まだ新しい機能のため、安定性がわからない。

WindowsのPython公式インストーラに付属するツールである、ランチャーとvenvを使う。

WindowsのPythonインストーラは、自動的にバージョン毎にフォルダを分けてインストールするなど複数バージョンの共存を前提としている。
その上で、実行するPythonのバージョンを「py.exe」というランチャーで切り替える運用をおすすめしている。

ランチャーだけでは「Python本体バージョンの分離・切り替え」「パッケージ環境の分離・切り替え」のうち前者だけしかできないが、 後者は「venv」という、これまた公式に最初から入っているモジュール（3.3以降）で実現できる。

本記事で扱う方法。

pyenv、pipenv、Anacondaなど、様々なPython用の環境分離ツールがあるのでそれを選んで使う。

pyenvは、先ほどの「ランチャー」がMacOSやLinuxでは提供されてないので、それらのOSでPython本体の分離によく使われるツールとなる。
Windowsでもpyenv-winという同様のツールがある。
3.x.y といったバージョン番号の“y”まで指定したいという場合や、現在のインストール状況をまるっと別PCに複製したい、という場合はこちらの方が手間が少ないかも。

pipenvやpoetryは、Pythonのモジュールとしてインストールし、「パッケージ環境の分離・切り替え」を司るツールとなる。
公式に取り入れられたvenvとできることが被っている感があるが、こちらの方が高機能。
特に、javascriptのpackage.jsonのようにインストールしたパッケージのリストだけでなくその依存関係を記録するため主と従が明確になり、 たとえば「Pandasを入れたらNumpyも自動的についてきたという環境で、Pandasをアンインストールすると、Numpyも同時にアンインストールされる」ようになっている。

Anacondaは、Python本体もパッケージも両方バージョン管理できる一体型。
「とりあえずこれさえインストールさえすればすぐに環境が整うものが欲しい」場合に便利な選択肢となる。
一方で、万能型だけに、パッケージ管理など一部機能がPythonの標準機能を覆い隠すため、特有のエラーが発生した時に情報が出てきにくいなど解決が難しくなることもある。

• Pythonにおける仮想環境「pyenv」について - Qiita
• pyenvとpyenv-virtualenvの自分流使い方 - Qiita
• pyenvが必要かどうかフローチャート - Qiita
• Pipfile/Pipfile.lockの必要性 -requirements.txtを用いる手法と比較して- - Qiita

ちょっと番外的になるが、有料だったり、時間制約付きだったりするものの 「それなりのものが揃った環境をインストール不要ですぐ使えて、ブラウザさえあればどこからでもアクセスできる」クラウド開発環境を使うのも手。

• AWS Cloud9（Cloud IDE でコードを記述、実行、デバッグ）| AWS
• 1. はじめに — ディープラーニング入門：Chainer チュートリアル

• OS環境ごと保全したい
  • → DockerなどOS単位の仮想化ツールを使う
• Python本体のバージョンを複数共存させたい
  • → 好みにより「(ランチャー or pyenv) + (venv or pipenv or poetry)」「Anaconda (Miniconda)」など
• パッケージ環境だけ、複数共存させたい
  • → 好みにより「venv」「pipenv」「poetry」「Anaconda (Miniconda)」

• 公式
  • Welcome to Python.org
  • 3. Windows で Python を使う — Python 3.9.4 ドキュメント

• Pythonの複数バージョンの扱い方（Windowsの場合） | ガンマソフト株式会社
• Pythonランチャで複数のPython環境を使い分ける | AsTechLog

欲しい版のインストーラを落として普通にダブルクリックからインストール。
他の版のPythonがインストール済みでも、重ねてインストールしてよい。

「Install Now」か「Customize installation」かはお好みで。

「Install launcher」にチェックすると、ランチャーがインストールされる。

このランチャーを使うと、複数バージョンのPythonがある時、一定の法則に従って使用するPythonのバージョンを切り替えることができる。

ランチャーを経由させるには、通常のコマンドでは

> python my_script.py

とするところを、

> py my_script.py

とする。

Pythonをそのままインストールした場合、3.9.x なら Python39 というフォルダにインストールされる。

• C:\Users\(username)\AppData\Local\Programs\Python\Python39

3.8.xなら Python38、といったように、ドットで分かたれた2番目のバージョン番号（マイナーバージョン）まではフォルダ別にインストールされる。 3番目のバージョン番号（マイクロバージョン）は主にバグフィックスで互換性も担保されているので、あまり最新版以外を使う必要性は薄く、上書きされる。

ランチャーは、以下の法則で実行する。

• 特に指定の無いとき、インストールされているバージョンの中から一番新しいもの
• コマンドライン引数でバージョンが与えられたとき、それに従う。
  • py -3.8 myscript.py
• シバン（実行する.pyファイル先頭に #!Python3.8 とか書くアレ）があるとき、それに従う

これで、実行するPythonバージョンを簡単に管理できる。

なお、この方法では pip コマンドを直接扱うことはできないが、Pythonモジュールとしての起動方法で使える。

(例)
> py -m pip install numpy

基本的に、環境変数のパスを設定する必要は無い。

ランチャーは C:\Windows\py.exe にインストールされるので、追加でパス設定せずともよい。

また、インストール時「Add Python 3.9 to PATH」にチェックを入れると、既定では以下の2箇所に環境変数のPATHが設定されて python と pip コマンドがどこからでも使えるようになる。

• C:\Users\(username)\AppData\Local\Programs\Python\Python39
• C:\Users\(username)\AppData\Local\Programs\Python\Python39\Scripts

最初はチェックされていないが、これは、基本はランチャーを使うのが推奨されているためと思われる。

環境変数を使うと、複数バージョンを入れたときに、うっかり後に入れた方が先のを上書きし、気付かずに思ったのと違うバージョンのPythonを使っていた、という事故が発生しうる。

その辺をちゃんと管理できて、やっぱり直接 python, pip コマンドを使えた方がいい、というのであれば、設定してもよいかも知れない。

• venv --- 仮想環境の作成 — Python 3.9.4 ドキュメント

仮想パッケージ環境の作成にあたり、公式が推奨している。 ¹⁾

主な使い方は、以下の通りとなる。

環境設定用のフォルダを作る場所を用意する。

%USERPROFILE% 以下でもいいし、プロジェクト毎に1環境を作る想定で、プロジェクト直下に配置してもいい。

> py -m venv (dir_name)

※(dir_name): 仮想環境フォルダ名

フォルダ dir_name が作成され、python.exeとかがそのフォルダにコピーされる。

なお、プロジェクト直下に配置する場合、フォルダ名は .venv が通常使われる。

バージョンは、仮想環境を作成する際に使用した（py -m venv ○○ を実行した）Pythonバージョンとなる。
つまり、3.8と3.9が入ったPCで、3.8の環境を作りたい場合は、以下のようにする。

> py -3.8 -m venv (dir_name)

コマンドプロンプト上でその環境のフォルダ内にある Scripts/activate.bat を実行。

> (dir_name)/Scripts/activate.bat

PowerShell上では、Scripts/Activate.ps1。

すると、環境変数などが一時的に書き換わり、その環境が使われるようになる。

こうすると、PATHを通して無くても python や pip コマンドが使えるようになる。

> deactivate

callをつける。

call ○○/Scripts/Activate.bat

python 好きなスクリプト.py

call deactivate

希望のPythonバージョンでvenvモジュールを使い、–upgradeする

py -m venv xxx --upgrade

xxxは仮想環境のルートフォルダ（作成時にdir_nameで指定した名前）までのパス。

別にvenvを使う場合に限った話ではないが、Numpyでは、Intelの高速なライブラリを使い Intel製CPUにおいて高速に動作するMKL（Math Kernel Library）を用いるようにコンパイルされたものがある。

何もせずpipからインストールすると、それが使われないものが入る。

MKL版を使う場合は、Windowsなら、（自力でコンパイルすることも出来るが）gohlke氏が公開しているバイナリ化済みパッケージを使うのが手っ取り早い。

• Python Extension Packages for Windows - Christoph Gohlke

新規環境を作った際は、他のモジュールのインストール前に、Numpyだけここから落としてwheelからインストールするようにすると、CPUによっては演算が速くなる。

ただ、一部のモジュール（タイミングにも依るが、TensorflowやOpenCVなど）では、最新版のNumpyではモジュールが依存関係的に対応していないことがあり、少し前のNumpyが必要になることがある。
これはモジュール依存なので、一概にどれを入れておけばよいとかは言いづらい。

tensorflowを後から入れると、勝手に最新のNumpyが削除され新しく少し前のNumpyが入れられていたりする。

環境作りたてでエラーが発生したらまた作り直せばよいが、実際に使い始めてからエラーが起こると悲劇。
せっかく環境をvenvで分けられる利点を活かし、各環境はなるべく目的に特化させ、使うモジュールは最初に全てインストールできれば、それが一番である。