初めに

最近，PCを修理し，それまで利用していたPython環境を再構築することになった．

非常に良い機会だと思うので，イチから環境構築する過程を記録しようと思う．

過去の投稿では，かなり大雑把に記した気がするので，本稿はもう少し丁寧にウォークスルーして差別化しようと思う．

OSはWindows 10（64-bit）である（Windows 11ユーザーの友人にも試してもらったが，同じ手順が適用できた）．

注意
環境構築ではAnacondaが有名だが，~~著者はAnacondaアンチなので~~ Anacondaは大きすぎて嫌 + condaコマンドが面倒なので¹，もう少し軽量で管理が簡単な（だと思う）方法を紹介する．もしAnacondaユーザーが本稿に記載の方法に乗り換える場合は，まず，Anacondaをアンインストールしてから，手順に従っていただきたい．

誤解が無いよう記しておくと，「著者がAnacondaを避け，本稿を記載の方法を選んだ」だけである．この方法を薦める意思は全く無い．環境構築の方法は複数あるから，各ユーザーが自分で選択すれば良い．

環境構築

仮想環境

本稿は， 仮想環境を作ることを念頭に置いている．仮想環境を構築することの重要性は，

環境ぶっ壊れの心配が少ない（精神衛生上極めて重要）
複数のPythonを切り替えて利用できる
複数のパッケージを切り分けてインストール・利用できる

ことなどにあるだろう．

環境ぶっ壊れって？
著者の造語だが，以下のような状況を指す．
一旦苦労して環境を作ったものの，新しいパッケージが必要となり，それをインストールすると既にあった他パッケージとのバッティングが起き，じゃあこっちを消してこっちを入れて，色々やってる内に環境がしっちゃかめっちゃかに，，またイチから環境を作り直そうかな，，（θ~θ;）ﾔﾚﾔﾚ

項目2，項目3については，複数の作業をしているときに，

Project	A	B	C
`Python version`	`=3.12.1`	`<=3.8.10`	`>3.7.2`

など，複数のPythonを使う必要に迫られる場合に対応するためである（現状はそうでなくても，Pythonを使っていると将来的にそうなる可能性は極めて高い）．また，特定のライブラリが特定のPythonバージョンでしか動かない場合などにも対応できるようになる（機械学習では，PCに搭載しているGPUによってインストールすべきTensorFlow / PyTorchのバージョンが決まっている場合もある）．

Python

まず，Pythonが無いことを確認する（既に有るなら，次のpyenv / pyenv-winへジャンプ）．Command Promptで，

$ python

と打つと，以下のようにMicrosoft Storeへ案内される．もしPythonが有れば，インストールされているPythonが呼び出されるはずなので，このタイミングでは未だPythonが無いことが分かる．

ここでGetをクリックしても良いのかもしれないが，

私がMicrosoft Storeからインストールしたことが無い
私はMicrosoft Storeからインストールする人を見たことが無い
公式が安心

という理由から，Python公式からインストールする．

Downloadsから，最新版のインストーラをダウンロードするか，View the full list of downloadsから目的に合わせたバージョンを選択する．

その後，インストーラを起動し，Add python.exe to PATHをチェックしてインストールする（2023/12/13現在，Python 3.12.1が最新のようだ）．

インストールできたら，Pythonが有ることを確認する．Command Promptで，

$ python

と打つと，以下のようにPythonが挨拶してくれる．

初めの行でPython 3.12.1が動いていることが分かる．また，標準パッケージのsysをインポートし，sys.versionが正しく実行できていることも分かる．一方，サードパーティ製であるnumpyは未だインストールしていないので，当然インポートできない．

pyenv / pyenv-win

インストール

Pythonのインストールと動作確認が終わったところで，pyenvをインストールする．

pyenvは，Pythonのバージョンを管理する便利ツールだが，WSL以外のWindowsでは動かない．そのため，Windowsではpyenv-winを利用する．

documentationを読めば，インストール法が5つ以上あることが分かる．documentationで最も簡単とされているPowerShellを利用する方法でも良いが，先ほど折角Pythonをインストールしたのだから，pipを使う方法を選択しよう（と言うか，このためにPythonをインストールしたようなものだ）．

documentationに従い，Command Promptで，

$ pip install pyenv-win --target %USERPROFILE%\\.pyenv

を実行する．

インストールできたようだ（pipのアップデートの案内が出ているが，pyenvとは別の話題なのでここでは放っておく）．最後に，環境変数の設定を済ませる（スクリーンショットを取り忘れたが，各々終えていただきたい）．

ここまで来たら，正常にインストールできたか確認する．Command Promptで，

$ pyenv --version

と打てば，pyenv 3.1.1が返ってくるので，正しくインストールできたらしい．また，

$ pyenv

で利用可能なコマンドが表示される．

Pythonのバージョン管理

documentationのQuick startやusageの受け売りだが，折角日本語の資料ということで丁寧に記そうと思う．

注意
pyenv-winのコマンドがpyenv ...となっているため，本稿では以降，pyenv-winのことをpyenvと呼ぶこととする．

まず，最初にインストールしたPythonのバージョンを確認しておく．Command Promptで，

$ python -V

を実行すると，Python 3.12.1が返ってくる．確かに，3.12.1をインストールしたのであった（ここは，各々インストールしたバージョンが違うだろうが，最初にインストールしたものが返ってくるはず）．

続いて，pyenvにPythonをインストールする（「もうPythonあるやん」って気持ちはぐっと堪えて）．Command Promptで，

$ pyenv install -l

を実行すれば，pyenvで利用可能なPythonバージョンが列挙される．縦に長すぎるので，

$ pyenv install -l | findstr 3.8

などとすれば，Python 3.8.xたちが表示されてもう少しだけ見やすい．この中から適当なPythonバージョンを選択し，インストールする．例えば，

$ pyenv install 3.8.10

を実行すれば，Python 3.8.10がインストールされる．

このタイミングで，再度

$ python
$ python -V

などを実行すると，以下のようになる．

さっきまで使えていたPythonが，，！と慌てる前に，メッセージを読むと，「pyenvで利用するPythonバージョンを指定せよ」とのこと．大人しく従う．

$ pyenv global 3.8.10

を実行すれば，globalで実行されるPythonがPython 3.8.10に固定される．なお，

$ pyenv global 3.12.1

を実行してもエラーになる．Python 3.12.1はPython公式からインストールしたもので，pyenv上にはインストールしていないからである．

試しに2つくらい入れよう．先ほどと同じ要領でPython 3.7.9をインストールし，今，pyenvにインストールされているPythonたちを表示する．

$ pyenv versions

返事は以下の通り．

インストールした3.7.9と3.8.10が表示されているが，globalに設定した3.8.10にスターが付けられている．この状態でのpython -Vの返事はPython 3.8.10であり，pythonを呼ぶとPython 3.8.10が起動した．以上より，globalで呼び出されるPythonがPython 3.8.10となっていることが分かる．切り替えたければ，pyenv global 3.7.9などとすれば良い．

明示的に確認したいときは，次のようにすれば良い．Pythonの使い方として，in-command実行が可能なので，例えば以下を実行する．

$ python -c "import sys; print(sys.executable)"

返事は以下．

これより，pyenv由来のPythonが呼び出されていることが分かる．

続いて，pyenv localの使い方を記す（今の状態は，pyenvに3.7.9と3.8.10があり，global==3.8.10である）．localの設定をしていないタイミングでは，

$ pyenv local

を実行しても，

という返事となる．メッセージは，「このディレクトリにはlocalの設定が無い」と言っているので，適当な作業ディレクトリに移動してから

$ pyenv local 3.7.9

としてみる．

（緑色のマスクは作業ディレクトリである）

global==3.8.10のまま，local==3.7.9となり，このディレクトリではPython 3.7.9が呼ばれている．因みに，pyenv local 3.7.9を実行したこの作業ディレクトリには.python-versionというファイルが作られ，その中には3.7.9とだけ書いてあった．

また，

この作業ディレクトリより上ではpython -Vの返事は3.8.10
この作業ディレクトリより下ではpython -Vの返事は3.7.9

となっており，localを設定した階層（.python-versionがある階層）以下では全てlocalを設定した階層の（つまり，.python-versionに記された）バージョンが使われることが分かる．

pyenvの利用
pyenvの利用により，複数のPythonバージョンが利用・管理できるようになる．

venv

仮想環境の構築とアクティベート

pyenvが終われば，もう全て終わったようなものである．

先に記した仮想環境の構築のためのツールがvenvな訳だが，これはPython 3.3以降のPython 3.xには標準で搭載されている．つまり，pyenvで3.3以降のPythonを入れておけば殆ど準備が済んでいる．

仮想環境の運用として，globalな仮想環境というのは違和感がある．どちらかというと，プロジェクト毎に違う環境が要求されるだろう．先ほどの作業ディレクトリを，あるプロジェクトの作業場とし，そこに仮想環境を作ることにする．

公式に従い，以下のコマンドで.venv_testという名前の仮想環境を作る．

$ python -m venv .venv_test

.venv_testという名前のディレクトリができる．これが（未だ空っぽの）仮想環境である．この仮想環境をアクティベートする．

$ . .venv_test/Scripts/activate

ただし，上記を実行すると，.venv_test/Scripts/Activate.ps1 cannot be loaded because running scripts is disabled on this system.などと表示され，アクティベートできない場合がある．これは，PowerShellで起きる場合が多いようだ（例えば，VSCodeのターミナルはデフォルトでPowerShellであり，これが起きることがある）．原因は，Microsoftの実行ポリシー（en / jp）にある．この解説は，こちらの記事が詳しい．

原因の完全な理解は置いておいて，取り敢えず，解決に注力する．公式もこの問題は認知しているようで，以下をPowerShellで実行すれば良い，としている．

$ Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

これをPowerShellで実行すると，「本当に良いか？」との警告が出るので，Yesと回答する．すると，先に記した仮想環境のアクティベートができるようになる．

仮想環境がアクティベートされている間，ターミナルは，

(.venv_test) $

などという待機状態になるだろう．ディアクティベートするには，

(.venv_test) $ deactivate

とすれば，仮想環境名の表示が消え，

という待機状態に戻るだろう．これは仮想環境が立ち上がっていない状態を示している．つまり，きちんとディアクティベートできた，という意味である．必要に応じて，また別の環境をアクティベートすれば良い．

なお，.venv_testのPythonは，Python 3.7.9になっている（.venv_testをアクティベートした状態でpython -Vを実行すれば，3.7.9が返ってくる）．なぜなら，このディレクトリではlocal==3.7.9の設定をしたからである．このとき，local==3.7.9が設定されているこのディレクトリより上の階層で仮想環境を作成し，バージョン確認すると，3.8.10が返ってくる．なぜなら，今はglobal==3.8.10の設定をしているからである．

このように，作業ディレクトリ毎に仮想環境を作るだけでなく，仮想環境毎に使うPythonバージョンの切り替えまで可能になる．また，他のPythonバージョンを使いたいならば，適宜pyenv install 3.x.xなどとしてから，global / localの設定を済ませ，python -m venv .venv_testで仮想環境を作れば良い．

仮想環境へのライブラリのインストール

めでたく仮想環境が構築できたわけだが，先に記したように，これは未だ空っぽである．つまり，標準ライブラリしか利用できない（数値計算も，機械学習も，グラフ描画もできない）．

試しに，

np_plt_test.py

import numpy as np
import matplotlib.pyplot as plt

def main():
    x = np.linspace(0., 2. * np.pi, 100)
    y = np.sin(x)

    plt.plot(x, y)
    plt.show()

if __name__ == "__main__":
    main()

というスクリプトを実行しても，No module named 'numpy'などと怒られる．

例えば，当該の仮想環境（.venv_testとする）でnumpyやmatplotlibを使いたいならば，当該環境をアクティベートした状態で，

(.venv_test) $ pip install numpy, matplotlib

してから再度，先ほどのスクリプトを実行すれば良い．上記のコマンドでは，当該のPythonに対応する中で最新バージョンのライブラリがインストールされる．あるいは，特定のバージョンが欲しいときには，

(.venv_test) $ pip install numpy==1.24.4

などとすれば良い．

一旦numpyをインストールしたが，間違ったバージョンを入れてしまった！という場合には，

(.venv_test) $ pip uninstall numpy

してから，再度，バージョンに気を付けながらインストールする．

また，開発環境を誰かと共有する場合や，過去に作った仮想環境に類似した環境を必要とする場合には，

(.venv_test) $ pip freeze > requirements.txt

を実行する．すると，同じ階層にrequirements.txtというファイルが作成される．同ファイルには，.venv_testで使われているライブラリのバージョンがnumpy==1.24.4という形式で記されている．

新しい環境（.venv_test2とする）で同じ環境を作るには（勿論，.venv_testをディアクティベートしてから，.venv_test2をアクティベートした状態で），

(.venv_test2) $ pip install -r requirements.txt

を実行する．これで，名前が違うが全く同じ仮想環境ができる．ここから，(.venv_test2)にだけ新しいライブラリを入れてみたり，幾つかのライブラリのバージョンを変えてみたり，ということが可能となる．

最後に，仮想環境を間違って作ってしまった場合や，もう使わないな，という場合は，.venv_testをディレクトリごと削除すれば良い．

$ rm -r .venv_test

先に記した環境ぶっ壊れが起きたとしても，それは当該の仮想環境だけの話だから，被害は最小限に留めることができる．この意味合いで安全である（他の仮想環境はぶっ壊れない）．

このようにして，目的に応じて仮想環境を切り分ければ，お互いのバージョン互換性などに悩まされることが少なくなる．

venvの利用
venvの利用により，仮想環境の構築，利用が簡便になる．

終わりに

久しぶりに，Pythonの環境を作るという作業をした．大きな問題もなく環境整備ができて良かった．また，その過程を本稿に記録することができて良かった．

特に，pyenvの使い方は良く理解していなかったので，発見があり，楽しかった．

ゆっくり書きすぎた気もするが，丁寧で損することは無いだろう．

こう書くと一方的に嫌っているように見えるが，著者もAnacondaを1年以上利用した経験がある．ただ食わず嫌いしているわけでは無い． ↩