「venv」の記事一覧

venvの必要性 Pythonバージョンの問題 問題 現在、Pythonは主に2系、3系が使われています。 プロジェクトによって、Pythonのバージョンを細かく指定したい場合、そのたびにPythonモジュールをインストールし、実行時に指定する必要があり、煩雑です。 venvによる解決 venvでは、使用するPythonインタプリタを仮想環境のbin/に保持します。ですので、仮想環境に切り替えさえすれば、目的のバージョンのPythonインタプリタを使用できます。 パッケージ管理の問題 問題 pipは、何も指定しなければ、グローバル領域にモジュールをインストールします。 プロジェクトAとプロジェクトBで同じモジュールを使用したいが、Aでは1.0.0、Bではv1.0.4を使うという制約がある場合等、手順が煩雑になります。 そもそもあるプロジェクトのみで使うモジュールを汎用的な用途の場所に配置するというのが気持ち悪いというのもあります。 (補足) --userオプションを付与することで、ユーザ領域の任意のフォルダにインストールすることはできます。 それに、モジュールごとに任意のローカルフォルダを指定することもできますが、毎回オプションを付けてインストールを行うのは複雑な手順になってしまいますし、ユーザに使用方法としてそれを強要するのは難しいものがあります。 venvによる解決 venvでは、$PATH・$PYTHONHOMEが書き換えられていることにより、pipのデフォルトインストール先がvenv仮想環境のフォルダ内となります。 プロジェクトに必要なモジュールはvenv内のみにインストールされることとなり、当然ながらプロジェクト間でバージョンの衝突を起こすこともありえません。 venvとは一体何なのか よく言われるのが、「Pythonのための仮想環境」という表現です。 これだけだとピンと来づらいので、venvのフォルダ構成と、使い方を見てみましょう。 $ python3.6 -m venv venv # venv環境を作成するコマンド $ tree -L 2 venv venv ├── bin │ ├── activate │ ├── pip │ ├── pip3 │ ├── pip3.6 │ ├── python -> python3.6 │ ├── python3 -> python3.6 │ ├── python3.6 -> /usr/bin/python3.6 │ ├── ... │ └── wheel ├── get-pip.py ├── include ├── lib │ └── python3.6 ├── lib64 -> lib └── pyvenv.cfg $ source venv/bin/activate # venv仮想環境を開始するコマンド $ deactivate # venv仮想環境を終了するコマンド source venv/bin/activateは、要するに、$PATHの内容を現在のフォルダのbinに置き換えるという処理を行っています。 deactivateでは、置き換えた$PATHを元通りに戻します。 まとめると以下のようになります。 Pythonの実行に必要な最小フォルダ構成(=仮想環境)を用意することができる activateファイルをsourceコマンドで読み込むと、PATHが書き換わり、Python系コマンド(pip等を含む)は「仮想環境」の中で動作するようになる。 要するに venvを使えば、思わぬ衝突や、動いていたはずのプロジェクトがいつのまにか動かなくなった等のトラブルを避けることができます。 小さいプロジェクトしか管理していなくても、自分以外使わない端末であっても、ミニマムな環境に保っておくことは重要です。 プロジェクトをはじめたら、venv環境を作り、その中で作業しましょう。

cod-log

「venv」の記事一覧

[Python] venvの使い方・導入手順

[Python] Ubuntu14.04 venv導入時エラー、その解決方法

[Python] venvとは？どんなときに便利？使う必要はある？