Venvで仮想環境を作成 by xrsns.com

Venvで仮想環境を作成

初回投稿日 2019-11-25 | 更新日 2020-02-03

• 目次
• 仮想環境にする理由
• 仮想環境にするメリットとデメリットまとめ
• Virtualenv(Venv)をインストールする
• 仮想環境の作成

説明では基本的にCUIでコマンドプロンプトからの利用を想定してます。

仮想環境にする理由

仮想化した状態でPuputとPyMySQLを入れて行きますが、
そもそも何故、仮想環境で作業する事を勧めるのか少し説明します。

(将来的に初心者の方でもWagtailを組めるように、初歩的な部分から説明してます。
理解してる場合は仮想環境にする理由の説明は飛ばして次に行ってください。
分かりやすく説明する為に、厳密な仕様とは異なる表現があるのをご理解ください。)

仮想化して作業を進める理由は、仮想化するメリットとして、
ライブラリ等のパッケージをインストールして行く際に、
プロジェクト毎に分けた方が便利な場合が多いからです。

仮想環境を設定しないと、、

Aにライブラリをインストールすると
Bにもライブラリがインストールされた事になる。

例えばAとBいうWagtailのプロジェクトがあったとします。
仮想化してない場合はAにPuput等のライブラリをインストールした場合、
Bにもインストールされた事になります。

その場合、Bではライブラリをインストールしてない状態でWagtailを使いたいと思ったら、
ライブラリをアンインストールする事になります。
そうすると、今度はAに入っていた筈のPuputもアンインストールされてしまいます。
その結果、AとBの両方でライブラリを利用出来なくなってしまいます。

この様な場合、仮想環境を設定する事で、
Aのみにライブラリをインストールしたり、Bのみにインストールする事が出来るようになります。

仮想環境を設定すると、、

Aにライブラリをインストールしても
Bにライブラリがインストールされる事はない。

個人的に大きいと感じてるメリットとしては、上記に付随する事ですが、
HerokuやGCPなどのサーバーにデプロイ(アップロードのようなもの)する際に、
ローカルでインストールしたライブラリのみで正しく動くかどうかを、
事前に試す事が出来る点です。

つまり、ライブラリ関係で、ローカルでは正常に動いていたんだけど、
デプロイしてみたら動かない、若しくは異なった動作をしてしまう様なトラブルが少なくなります。
個人的な経験からも、Heroku、GCPで一括でデプロイするような際は特に強くお勧めします。

一応、仮想環境を設定する際のデメリットにも触れておきたいと思います。
実際に仮想環境下でプロジェクトにライブラリをインストールして、動かしてみると良く分かると思いますが、
仮想環境を設定すると、通常はプロジェクトの下に設定したディレクトリにライブラリを入れて行く事になるので、
プロジェクト自体のファイルサイズが大きくなります。

プロジェクトが一つや二つなら大した問題にはなりませんが、
数百個のプロジェクトを作って、全てに沢山のライブラリをインストールして、
作業を進めて行きたいという様な場合は、
膨大なファイルサイズになるので、あまりお勧めしません。

とはいえ、そのような利用は通常は、あまりしないと思いますし、
20年前のパソコンなら兎も角、昨今のパソコンは記憶容量が増えてますので、
基本的には仮想環境を設定して作業を進めた方が、デメリットよりもメリットの方が大きいと思います。

ファイルサイズの他に考えられるデメリットとしては、
AとBのプロジェクトどちらにもDjangoやPuput等のライブラリを入れたい場合は、
それぞれインストールしないといけなくなるので手数は多少増えます。

仮想環境にするメリットとデメリットまとめ

仮想環境のメリット
ライブラリのインストールをプロジェクト毎に分けられるので、
プロジェクト毎にライブラリの導入状態を分けられる。
その結果、デプロイする際にも有利。

仮想環境のデメリット
プロジェクト毎にライブラリをインストールするので手間がかかる。
ファイルサイズが大きくなる。

Virtualenv(Venv)をインストールする

$ pip install virtualenv

$ pip install virtualenv
Collecting virtualenv
Downloading https://files.pythonhosted.org/～/virtualenv-16.7.8-py2.py3-none-any.whl (3.4MB)
100% |█████████| 3.4MB 6.3MB/s
Installing collected packages: virtualenv
Successfully installed virtualenv-16.7.8

それでは、仮想環境を作成する前に仮想化する為に、
Virtualenv(以下Venv)というライブラリをインストールして下さい。

まだ、Venvをインストールしてない場合は、
上記のようにコマンドプロンプトに入力してインストールしてください。

仮想環境の作成

現在のパス(URL)例
C:\Users\～\directoryA\myProject

PCのWindous(C:)のユーザー(Users)の下の任意のdirectoryAディレクトリ内に、
myProjectというWagtailのプロジェクトを作ってあると仮定して進めて行きます。

Wagtailのプロジェクト名であるmyProjectの部分は、任意の名前なので異なる可能性があります。
プロジェクト作成までは、 Wagtailの構築方法に記載してあります。

$ cd C:\Users\～\directoryA\myProject

Wagtailプロジェクトのトップのパスになってない場合は、
$ cd～でWagtailプロジェクトのトップディレクトリに移動してください。

$ virtualenv env

$ virtualenv env
～
Installing setuptools, pip, wheel...
done.

この説明では仮想化する環境の名前をenvとしてます。
プロジェクト内にenvディレクトリを作って仮想化します。

virtualenv 環境の名前

環境の名前の部分はenv以外の任意の名前でも動作します。

$ cd C:\Users\～\directoryA\myProject\env

envのディレクトリ内に移動してください。

$ scripts\activate

(env) $ scripts\activate

envディレクトリ内でscripts\activateと打ち込んで仮想環境の有効化をします。

現在のコマンドプロンプト内の表示例
(env) C:\Users\～\directoryA\myProject\env

簡略化しないで表記すると上記の様になってると思います。
Cの前に(env)という文字がついていれば仮想化されてます。

今後の各章の全ての説明は特別な断りが無い場合は、
コマンドプロンプトの表記は先頭に(env)が付いてると仮定して進めて行きます。

コマンドプロンプトの表記例に関して
(env) $ cd C:\Users\～\directoryA\myProject
↓
$ cd C:\Users\～\directoryA\myProject

仮想化をしないと動作が異なり、説明通りに動かない事が多いので特に注意して下さい。
全てに(env)を付ける記述も考えましたが、中級者以上にとっては寧ろ邪魔になる事も考慮しました。

$ cd C:\Users\～\directoryA\myProject

最後に元のWgtailプロジェクトのディレクトリのトップに移動して下さい。

$ deactivate

仮想環境をやめる場合はdeactivateと打ち込んで下さい。
仮想環境が解かれて先頭の(env)が消えます。

次のセクションでバージョンについて学んだ後、
実際にPuput等のライブラリをインストールして行くので、
必ず仮想環境を設定した状態にしておいて下さい。

次は仮想化した環境下で、実際にPuput等のライブラリをインストールして行きます。

次の記事