本番サーバで仮想環境を使うかどうか。

PythonやRuby、Golangなどの言語には、仮想環境を作り出すことで

• 異なるバージョンの言語を安全に利用できる
• 利用しているモジュールのバージョンを他の環境から隔離できる
• 仮想環境外のサービス（httpサーバなど）もそのまま使える
• 特定のバージョンでしか動かないアプリを安全に動かすことができる

という利点が生まれます。

一方、欠点としては

• それぞれの仮想環境でのバージョン管理を個別に行う必要がある
• セキュリティアップデート時などの管理が煩雑になる
• 同じモジュールをいくつもインストールすることになる場合はディスク容量を消費する

などがあります。

当然ながらこの手の記事は検索すればたくさん出てくるため、これは自分用のメモです。しかもPython専用です。

Pythonではメジャーバージョンアップ（2K→3K）でもマイナーバージョンアップ（3.3→3.4など）でも言語仕様含めいろいろと変わっています。そのため、バージョンアップで非推奨となったり廃止されたりするものもあり、特定のバージョンに依存した実装は影響を受ける場合があります。

たとえばGNU Mailmanはバージョン 2.1系ではPython 2.7を前提としており、バージョン3系はPython 3.5以降を前提としています。バージョン 3系はPyPiでリリースされているため、今のところ個別のパッケージを用意しているのはDebian系のみのようです。つまり、インストールは pip を使って行いますが、それだとグローバルな環境にmailmanをインストールすることになります。もちろんそれでもいいという人もいるかも知れませんし、パッケージベースでの管理のほうが好みだという人もいるでしょう。
しかしながら、たとえば mailman のバージョンが上がったときにどうやって互換性などの問題がないことを確認するのかを考えると、別途仮想環境を作って確認するというのはひとつの解決方法になります。特に、設定ファイルなどの変更が必要になるような場合には有効でしょう。

サーバ上で動いているすべてのPythonアプリケーションが、いずれも最新バージョンのPythonとモジュールで動作するのであれば問題ありませんが、ある特定のバージョンに依存しているような場合を考えると、サーバ上でも積極的に仮想環境で運用するのは一つの考え方です。
特に、システムワイドでインストールしたモジュールをサーバ側でも使用するようなときには、相互に影響を及ぼさないようにサーバ側を仮想環境で保護するということが必要にもなってくるでしょう。

ということでPythonの仮想環境ですが、これまで有名なものには virtualenv や pyenv などがあります。が、Python 3.3から仮想環境を構築するモジュールが venv という形で取り込まれています。つまり、Python 3.3以降では virtualenv などをインストールする必要はありません。自分は現在は Python 3.7をメインで使用していますので、venv を使っていくことになるでしょう。

一応 venv を使う手順をまとめると、

python -m venv [プロジェクト名]

で仮想環境を作って、

$ cd [プロジェクト名]
$ Scripts/activate
（なんかの作業）
$ deactivate

という感じです。UNIX環境では、batファイルを実行する代わりに source します。

ただし、Python 2.7を使うときには virtualenv を使います。

それから、Linux系でsystemdを使ってvenv / virtualenvのサービスを自動起動したい場合にはどうするかという議論がStackoverflowにありましたので参考まで。

How to enable a virtualenv in a systemd service unit?