2012-02-13 1 views
2

私は私の状況を管理するために、2つのアプローチのうち、決定したかった、サードパーティのアプリの多くを使用してDjangoのプロジェクトを持っている:Django:[virtualenv + pip]と[svnの手動でパッケージを運ぶ]どちらの方が良いですか?

  1. 私はpip freezeとともに[virtualenvの+ PIP]を使用することができます私のプロジェクトの依存関係を管理するための要件ファイルとして。

    私はアプリを心配する必要はありませんが、SVNの私のコードをコミットしていることはできません。

  2. 私は私のsvn構造にlibフォルダがあり、この方法は、私のアプリはそこに座っており、sys.path
にそれを追加することができ、私の依存関係は、SVNにコミットすることができますが、私は sys.path

を管理する必要が

どのようにすればいいですか?

賛否両論それぞれのアプローチは何ですか?

更新:

方法1デメリット:難しいのAppEngineで動作します。

+1

http://guide.python-distribute.org/pip.html#installing-from-a-vcs – DrTyrsa

+0

リンクをありがとうが、私はsvnのlibを持っていないと思う。 。私はリンクを調べ、必要に応じて元に戻します。 :) –

答えて

0

これまでのところ未回答の質問です。この上でいくつかの議論が最近あります: -

https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE

イアンBickingはコメントでこれを言った: -

を、私たちは両方のシステムが組み込まれて何かを行うことができると思います。 I は、これを早期に処理するためのレシピを投稿しました(私は をクリーンアップして再ポストする必要があります)。あなたは非常に のライブラリをPythonで同様に処理できますが、まだそれらのライブラリを管理するツールを使用しています。 あなたはそれを行うことができますが、それは全く理解できませんので、人々はデプロイ時にパッケージ を再インストールするようなことに頼る傾向があります。

http://tarekziade.wordpress.com/2012/02/10/defining-a-wsgi-app-deployment-standard/

最初のアプローチは、Pythonの開発者の間で最も一般的なようです。私が最初にDjangoで開発を始めたとき、PHPを実行するとサードパーティ製のlibをプロジェクトリポジトリにチェックするのが一般的でしたが、Ian Bickingがリンク先で言ったように、PHPスタイルのデプロイメントは、ポータブルライブラリ。 mysqldbやPILなどのものをあなたのプロジェクトにパッケージ化したくない場合は、Pipや配布などのツールでよりうまく処理できます。

+0

あなたは質問自体についていくつかの立場を持っています。質問自体にそれらを加えることを検討することができ、私たちは解決策を待つことができます。 –

0

これは私が現在使用しているものです。

すべてのプロジェクトには、プロジェクトルートに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 

を:

  1. 我々はまだ依存関係を管理するために、PIP + virtualenvのを使用しています。
  2. 導入時に要件を再インストールする必要はありません。
  3. パスをsys.pathに少し保持する必要があります。
+0

この場合、buildoutを使用しないのはなぜですか? –

+0

私は別の複雑さを導入したくないし、ビルドアウトレシピで戦うことは楽しいことではありません。私は快適に感じたら、私たちのチームにそれを紹介するかもしれませんが、今はそうではありません。私たちのプロジェクトのルートにbinディレクトリを持っている以外に、私はそれがpipよりどれだけの利点を持っているのかわかりません。 – k4ml

+0

Hm .. 'Buildout' =' fabric + virtualenv + pip' 私はbuildoutを推奨していません。 依存関係、環境を管理するためのより成熟した明示的な方法であると考えられています。 人為的なエラーが起こりにくい! 私は 'pip + virtualenv'を使い、Buildoutを試してみたいと思います。 –

0

Virtualenvとpipは、1台のマシン上で複数のdjangoプロジェクトを処理するのに素晴らしいです。ただし、編集中のプロジェクトが1つしかない場合は、virtualenvを使用する必要はありません。

関連する問題