Python-pyenvとvenvという「見えない基盤」
Pythonを使って何かを作ろうとしたとき、最初につまずきやすいのが「環境」の問題だ。 ライブラリが動かない、バージョンが合わない、昨日まで動いていたコードが今日は動かない。
それらの多くは、コードそのものではなく、 Pythonをどう管理しているかに原因がある。 pyenvとvenvは、この問題を静かに、しかし確実に解消するための道具だ。
Pythonの「環境問題」はどこで起きるのか
多くの場合、問題は次の瞬間に発生する。
pip install ○○この一行を、どのPythonに対して実行しているのか。 それを意識しないまま作業を続けると、 環境は少しずつ歪んでいく。
ただし、最初から問題が起きるわけではない。 むしろ、しばらくは何事もなく動く。
かつては、pip install で十分だった
Pythonの初期の使われ方は、もっとシンプルだった。
- Pythonは1つだけ
- プロジェクトも1つ
- 短いスクリプトや個人用途が中心
この前提では、
pip install ○○で何の問題も起きない。 実際、それで十分だったし、それが正解だった。
当時は、Pythonの環境を「管理する」という発想そのものが、 あまり必要とされていなかった。
前提が変わり、問題が見えるようになった
その後、Pythonの使われ方は大きく広がっていく。
- Webアプリケーション
- AI・機械学習
- 長期間動かし続けるツール
プロジェクトは増え、Pythonのバージョンも増えた。 変化は速く、すべての人が同じ足並みで進むわけではない。
問題は、ある条件を超えたときにだけ、突然姿を見せる。
pyenv ― Pythonそのものを切り替える
pyenvは、Python本体のバージョン管理を行うツールだ。 Pythonが一つであるという前提が崩れたあと、 必要になってきた道具とも言える。
Pythonをインストールする
pyenv install 3.12.1
pyenv install 3.9.18これで、同一マシン上に複数のPythonが共存する。 OS標準のPythonには一切触れない。
プロジェクトごとにPythonを固定する
pyenv local 3.12.1このディレクトリ以下では、自動的にPython 3.12.1が使われる。
python --versionと打つだけで、今どのPythonが使われているかが分かる。 Pythonの「バージョン問題」は、ここでほぼ終わる。
venv ― ライブラリの世界を分離する
次に必要になるのがvenvだ。 これは、ライブラリ単位で環境を分けるための仕組みである。
仮想環境を作成する
python -m venv .venvこれで、.venv という独立したPython環境が作られる。
仮想環境を有効化する
source .venv/bin/activate（Windowsの場合は .venv\Scripts\activate）
有効化すると、ターミナルの表示が変わる。 これは「今はこのプロジェクト専用の世界にいる」という合図だ。
pyenv × venv が生む、静かな安心感
整理すると、流れはこうなる。
- pyenvで「どのPythonを使うか」を決める
- venvで「どのライブラリ世界を使うか」を分ける
この構造を一度作ってしまえば、 環境は混ざらず、壊れても戻れる。
それは、派手な解決ではない。 だが、長くPythonを使い続けるうえで、 確かな安心感を与えてくれる。
まとめ ― 途中で必須になる基盤
一つのPythonを使い続けて、何も困らない人もいる。 それはそれで、正しい。
一方で、ある地点を超えたとき、 環境を整理する必要に迫られる人もいる。 そのとき初めて、pyenvやvenvは意味を持つ。
Pythonの環境管理に、万能の正解はない。 ただ、変化の速い世界で作り続けるための 見えない基盤として、 pyenvとvenvは静かに支えている。
コメント