virtualenvwrapper でプロジェクト管理とか

ちょうど 1 年前にリリースされてた機能だけど、恥ずかしながら知らなかった。@t2y 先生が紹介していらっしゃって、後で試してみようと思ってたのですが...。virtualenvwrapper ってインストール時にグローバルな site-packages に放り込んで、後は。。。って感じ。あんま見直したことなかったのですが、プロジェクト管理以外にも結構色んな機能が追加されてるんですね。mkvirtualenv, workon だけじゃない！

ドキュメントを和訳してくださっている @t2y さんに多謝。基本的な機能やコマンド (と思いこんでいた mkvirtualenv, workon, etc...) についてはvirtualenv, virtualenvwrapper, pip を使う方法 by @IanMLewis さん, Pythonを取り巻く開発環境 (PyCon JP 2012資料 #pyconjp) by @ymotongpoo さんの記事が参考になります。

>>> mkvirtualenv

v3.3 から新しいオプションが増えてたんですね。これも知りませんでした。

  • -a <path/to/project>: プロジェクトに新しい env を関連付ける (後述)
  • -i <library_to_install>: env 作成と同時に、インストールしたいライブラリを指定する
    mkvirtualenv -i django -i django-celery-with-redis <env_name> のように複数指定できる
  • -r <path to requirements file>: env を作り requirements.txt 等指定したファイルに記載したライブラリを一括でインストールできる。個人的にこれは一番うれしいかも
    mkvirtualenv -r ./requirements.txt <env_name> ラクダーーー

>>> mktmpenv

これも v3.3 から。ユニークな名前で env 作成してくれる。

>>> cdvirtualenv, cdsitepackages

これは前からある。結構使う。私は activate, deactivate はよく書き換えるので、後述の cdproject と一緒に使うと幸せになれる。

>>> lsvirtualenv, lssitepackages

これも前からある。あんま使ったことない。workon, pip freeze -l でなれちゃってる。でも出力結果が細かかったり、lssitepackages は入力速くなりそう。

>>> add2virtualenv

これも前から。でも使ってる人あんま見たことない。add2virtualenv <path/to/external_libs> で、指定したディレクトリをカレント env に追加する。Django とか PySide 等でかいプロジェクトをいちいちチェックアウトしたくない場合を想定してあるらしい。これはシンボリックリンク、PIP_DOWNLOAD_CACHE, pip2pi とか色々解決方法があるけど、プロジェクトごとにライブラリのバージョン違ったりするので、今のとこ env 毎に全部インストールしちゃってる。

>>> toggleglobalsitepackages

v3.3 から。これ知らなかったのは辛い...。グローバル site-packages に入れてるのは、bpython, tox, py.test, mock, virtualenvwrapper などなど。setup.py で test_requires に書いてあるやつとか, requirements.txt にも書いてないライブラリーは基本グローバルに放り込んでる。グローバルが汚れるのはもちろん嫌だけど、env もなるべく汚したくない。使いたい時だけグローバル site-packages をパスに追加する。動作は virtualenv でやってたのと同様に "no-global-site-packages.txt" を作成したり、削除したりしてるだけです。ありがたい。

>>> mkproject

本題。v3.3 から。もともとプラグインで提供されてたらしい。1 プロジェクト 1 env。
mkproject [-t <project_template>] [mkvirtualenv options] <env_name>

環境変数で指定された PROJECT_HOME にプロジェクトディレクトリを追加、かつ WORKON_HOME に対応する env を作ってくれる。env 名はプロジェクトディレクトリ名になります。

プロジェクト作成時用の素敵なテンプレート機能も用意されています。テンプレートは github, bitbucket, django, flask 等色々。例えば mkproject -t github <env_name> ってやると github 上に env 名のプロジェクトを作ってくれます。mkproject -t django <env_name> ってやると、django-admin create project <env_name> を実行して、スケルトン作ってくれます。

>>> setvirtualenvproject

setvirtualenvproject <virtualenv_path> <project_path> で既存の env とプロジェクトディレクトリをひもづけてくれる。

>>> cdproject

アクティブな env に関連付けられたプロジェクトディレクトリに飛んでくれる。コンソール開いて workon <env_name>; cdproject ってやると env 適用して、対応するプロジェクトディレクトリをカレントディレクトリにしてくれるという。素敵ですね！

たまにはグローバルな site-packages に入れっぱなしのライブラリーも見直してみるもんですね。

コメント

コメントを投稿

このブログの人気の投稿

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む

#PySpa アドベント (23 日目)

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。
続きを読む