Pipenvに移行した話

Pipenv がPyPAに移ってからしばらく経ちました。 以前個人のPC環境は virtualenvwrapper を使用していましたが、折を見て自分も pipenv に移行しました。

理由は次の3つです。

  • virtualenvwrapper スクリプトが bash 起動を遅くする原因になっていた

  • Windows/macOS/Linux問わず同じように使いたかった

  • peco&ghq でのディレクトリの移動や管理に慣れてきた (peco&ghq に関する記事は探すと色々あったのでこの記事では割愛します。)

現在主に使う環境はこんな感じでやってます。

OS

macOS Sierra/Ubuntu 17.10

Python

3.6.x

pipenv

11.8.0

Pipenvとはなんぞや

稲田さんのツイートによるとこうです。

要は pip と virtualenv (と requirements.txt) をいい感じにラップしてくれるツールです。 インストール方法やどんなことができるか詳しくは Pipenv: 人間のためのPython開発ワークフロー を参照してください。

冒頭にある動画を見るとどんなことができるかイメージがつくと思います。

個人的Pipenvとの付き合い方

前述の通り、Pipenvは pip と virtualenv をいい感じにラップしてくれるツールなのですが、以下のルールで使用しています。

  • PIPENV_VENV_IN_PROJECT=true にしてプロジェクトのディレクトリに .venv を作成する

  • $HOME のようなプロジェクトのディレクトリ以外の場所に requirements.txt や Pipfile を残置しない

  • 困ったときは pip と virtualenv の使い方にならう

PIPENV_VENV_IN_PROJECT=true を設定

これを bashrc などに設定しておくと、プロジェクトディレクトリ(~/projects/hoge など)で pipenv install/shell した時に ~/projects/hoge/.venv となるように仮想環境を作成してくれます。

デフォルトの挙動だと /Users/<username>/.local/share/virtualenvs/プロジェクトのディレクトリ名+ハッシュ値 のように仮想環境名が決まるため、どこを指定すればいいのかわかりにくいです。これが PyCharm や VSCode で仮想環境を設定するときに面倒でした。

プロジェクトディレクトリに仮想環境が作成されることで、その欠点が解消できます。

Note

WORKON_HOMEを指定すると、指定した箇所にまとめて仮想環境を作成してくれます。 仮想環境を作成する場所をまとめたい時は export WORKON_HOME=~/.virtualenvs などとするとよいです。

requirements.txt や Pipfile を放置しない

ホームディレクトリ ( $HOME )に requirements.txt や Pipfile を放置していた結果、 個別のプロジェクトディレクトリ以下で pipenv install するときに意図しないライブラリがインストールされました。

原因は $HOME に放置していた pipenv や Pipfile を読み込んでいたからでした。 しかし $HOME に置いていたファイルが影響するとは想定していませんでしたので、 プロジェクトのディレクトリ以外に requirements.txt や Pipfile を放置しないようにしました。

困ったときは pip と virtualenv に戻る

pipenv に移行しましたが、「 pipenv は pip と virtualenv をいい感じにしたい」から使っています。 なので個人的には、次のようにコマンドを置き換えて使ってる感じです。

virtualenvの場合

pipenvの場合

virtualenv .venv

pipenv install/shell

souce .venv/bin/activate

pipenv shell

deactivate

exit

pip install とかは普通に使ってますし、 requirements.txt も現役です。

注意すべきところとして、 pipenv はそれ自体で単体のツールではなく複数のライブラリを組み合わせて使用するものだということです。 何かトラブルが起きた時は最低限 pip と virtualenv の使い方が理解できていないとツラいかもしれません。

2018/03/15時点での依存関係は次のとおりです。

(test)kashewnuts@ubuntu:test$ pipenv graph

pipenv==11.8.0
  - certifi [required: Any, installed: 2018.1.18]
  - pip [required: >=9.0.1, installed: 9.0.1]
  - setuptools [required: >=36.2.1, installed: 38.5.2]
  - virtualenv [required: Any, installed: 15.1.0]
  - virtualenv-clone [required: >=0.2.5, installed: 0.3.0]

触り始めの pipenv==8.2.x と比べて依存するライブラリが必要なものに絞られてきて、いい感じになってきました。 しかし、 virtualenv+pip をラップして使うため予期せぬ不具合を踏むこともあります。 そんなときは pipenv の問題なのか、それとも virtualenv や pip の問題なのかを切り分けて考えるとよいと思います。

実際どうなのよ

「普通にvirtualenv/venv+pip使えばいいじゃん」という方には不要なものだと思います。

個人的には結構便利です。ただ慣れるまでハマりどころはあるかもしれません。

virtualenvwrapper が担っていていたプロジェクトへの移動を peco&ghq でできるようにしたので、 pipenv にそれ以外のところを任せられてる感じです。

Pythonに限った話だと virtualenvwrapper の方が「仮想環境の管理」＋「自動activate」とセットで機能が提供されているので楽でした。 workon projectname で「自動activate」+「プロジェクトディレクトリへの移動」なんかもできましたし安定していました。

しかし「 .env ファイルを自動で読み込んでくれると嬉しいな」とか、Windows/macOS/Linuxと共通の手順で導入できるし、 peco&ghq を活用すればディレクトリの移動もお楽にいけそうだと思ったので、「個人でよしなにやるプロジェクトなら pipenv の組み合わせでいいかー」と思い移行することにしました。

今のところ個人の環境でしか試してないので、本番環境で運用したりしてる人はどうしているのかなとは気になりますね。


Posted by Kashun YOSHIDA
Filed under: Python
Tags: Python