これは私が現在使用しているものです。
すべてのプロジェクトには、プロジェクトルートにvirtualenvディレクトリがあります。私たちはそれを名前にします。env、vcsで無視してください。最初の開発で開発を始めるときには、このvirtualenvを初期化し、requirements.txtファイルで指定されたすべての要件をインストールします。私は、プロジェクトディレクトリ内にvirtualenvを持っている方が好きです。つまり、$HOME/.virtualenv
のような他の場所ではなく、環境をアクティブにするためにsource $HOME/virtualenv/project_name/bin/activate
を実行するよりも、開発者には明らかです。代わりに、開発者のような、プロジェクトのルートからの直接のenv実行可能ファイルを呼び出すことによってvirtualenvのとの対話: - 展開するには
.env/bin/python
.env/bin/python manage.py runserver
、我々は最初に.envディレクトリと一緒に私たちのプロジェクトディレクトリをエクスポートします生地のスクリプトを持っていますtarballをライブサーバーにコピーし、展開ディレクトリをuntarし、サーバーの再起動などの他のタスクを実行します。ライブサーバーでtarballをuntarするとき、ファブリックスクリプトはvirtualenvを再度実行して、すべてのシバンパス.env/bin
に固定されます。つまり、ライブサーバーに依存関係を再インストールする必要はありません。
fab create_release:1.1 # create release-1.1.tar.gz
fab deploy:1.1 # copy release-1.1.tar.gz to live server and do the deployment tasks
fab deploy:1.1,reset_env=1 # same as above but recreate virtualenv and re-install all dependencies
fab deploy:1.1,update_pkg=1 # only reinstall deps but do not destroy previous virtualenv like above
我々はまた、setup.pyを使用してvirtualenvのにプロジェクトsrcをインストール代わりのsys.pathにパスを追加しないでください - :展開のための生地のワークフローは次のようになります。 mod_wsgiの下に配置するときに、私たちは、mod_wsgiのための私達のバーチャルホストの設定でのようなもの2つのパスを指定する必要があります - 要するに
WSGIDaemonProcess project1 user=joe group=joe processes=1 threads=25 python-path=/path/to/project1/.env/lib/python2.6/site-packages:/path/to/project1/src
を:
- 我々はまだ依存関係を管理するために、PIP + virtualenvのを使用しています。
- 導入時に要件を再インストールする必要はありません。
- パスをsys.pathに少し保持する必要があります。
http://guide.python-distribute.org/pip.html#installing-from-a-vcs – DrTyrsa
リンクをありがとうが、私はsvnのlibを持っていないと思う。 。私はリンクを調べ、必要に応じて元に戻します。 :) –