目次

Pythonインストール（venv）

想定環境

インストール前に考慮すべき点

Pythonを使ったことがないなら

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

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

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

環境分離ツール

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

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

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

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

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

環境分離ツールの種類

コンテナ化/仮想化

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のインストール

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

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

ランチャー

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

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

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

> python my_script.py

とするところを、 

> py my_script.py

とする。

ランチャーの挙動

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

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

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

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

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

(例)
> py -m pip install numpy

パス設定

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

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

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

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

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

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

venv

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

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

仮想環境作成の手順

場所の用意

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

%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のバージョンアップ

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

py -m venv xxx --upgrade

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

その他

Numpyのインストール

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

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

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

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

最新のNumpyでは上手くいかないモジュールも

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

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

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

1)
3.4まではpyvenvというツールが推奨されていたが、virtualenvというツールの機能がvenvという名でPythonの標準機能に取り込まれ、そこからはvenvが推奨されるようになった