新しい開発者がチームに参加するとき、またはJenkinsが完全なビルドを実行するとき、新しいvirtualenvを作成する必要があります。 Pipと多数(10以上)の要件でvirtualenvを設定すると、PyPIからすべてをインストールするのに非常に長い時間がかかることがよくあります。しばしばそれは完全に失敗します:
Downloading/unpacking Django==1.4.5 (from -r requirements.pip (line 1))
Exception:
Traceback (most recent call last):
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/basecommand.py", line 107, in main
status = self.run(options, args)
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/commands/install.py", line 256, in run
requirement_set.prepare_files(Finder, force_root_Egg_info=self.bundle, bundle=self.bundle)
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/req.py", line 1018, in prepare_files
self.unpack_url(url, location, self.is_download)
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/req.py", line 1142, in unpack_url
retval = unpack_http_url(link, location, self.download_cache, self.download_dir)
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/download.py", line 463, in unpack_http_url
download_hash = _download_url(resp, link, temp_location)
File "/var/lib/jenkins/jobs/hermes-web/workspace/web/.venv/lib/python2.6/site-packages/pip-1.2.1-py2.6.Egg/pip/download.py", line 380, in _download_url
chunk = resp.read(4096)
File "/usr/lib64/python2.6/socket.py", line 353, in read
data = self._sock.recv(left)
File "/usr/lib64/python2.6/httplib.py", line 538, in read
s = self.fp.read(amt)
File "/usr/lib64/python2.6/socket.py", line 353, in read
data = self._sock.recv(left)
timeout: timed out
私はPipの--use-mirrors
フラグを認識しており、時々私のチームのメンバーは--index-url http://f.pypi.python.org/simple
(または別のミラー)を使用して、タイムリーに応答するミラーができるまで回避しました。私たちは英国にいますが、ドイツにPyPIミラーがあり、他のサイトからのデータのダウンロードに問題はありません。
それで、私はチームの内部でPyPIをミラーリングする方法を探しています。
私が調べたオプションは次のとおりです。
自分のPyPIインスタンスを実行しています。公式のPyPI実装があります: CheeseShop だけでなく、次のようなサードパーティの実装もあります: djangopypi および pypiserver (脚注を参照)
このアプローチの問題は、ファイルのアップロードによるPyPIの完全な機能に興味がなく、それが提供するコンテンツをミラーリングすることだけです。
pep381client または pypi-mirror でPyPIミラーを実行します。
これはうまくいくように見えますが、最初にPyPIからすべてをダウンロードするにはミラーが必要です。 pep381clientのテストインスタンスを設定しましたが、ダウンロード速度は5 Kb/sと200 Kb/s(ビットではなくバイト)の間で変化します) 。完全なPyPIアーカイブのコピーがどこかにない限り、便利なミラーを作成するには数週間かかります。
yopypi などのPyPIラウンドロビンプロキシを使用する。
http://pypi.python.org 自体が 地理的に異なるいくつかのサーバー で構成されているため、これは関係ありません。
開発者間でvirtualenvをコピーするか、または 現在のプロジェクトの依存関係のフォルダー をホストします。
これはスケールしません:いくつかの異なるPythonプロジェクトの依存関係が時間とともに(ゆっくりと)変化します。プロジェクトの依存関係が変化したらすぐに、この中央フォルダーを更新して新しいプロジェクトを追加する必要があります。依存関係です。Python Cモジュールを含むパッケージはすべて、ターゲットシステム用にコンパイルする必要があるため、virtualenvをコピーすることはパッケージをコピーするよりも悪いことです。私たちのチームにはLinuxとOS Xの両方のユーザーがいます。
(これはまだ悪い束の最良の選択肢のように見えます。)
インテリジェントなPyPIキャッシングプロキシの使用: collective.eggproxy
これは非常に良い解決策のようですが、 PyPIの最後のバージョンは2009年の日付です で、mod_pythonについて説明しています。
他の大きなPythonチームは何をしますか?pythonパッケージの同じセットをすばやくインストールするための最良の解決策は何ですか?
脚注:
共有ファイルシステムはありますか?
私はpipのキャッシュ設定を使用するためです。とても簡単です。たとえば/ mntにpip-cacheというフォルダを作成します。
mkdir /mnt/pip-cache
次に、各開発者は次の行をpip構成に追加します(unix = $ HOME/.pip/pip.conf、win =%HOME%\ pip\pip.ini)
[global]
download-cache = /mnt/pip-cache
それはまだPyPiをチェックし、最新バージョンを探します。次に、そのバージョンがキャッシュにあるかどうかを確認します。もしそうなら、そこからインストールします。そうでない場合はダウンロードします。キャッシュに保存してインストールします。したがって、各パッケージは新しいバージョンごとに1回だけダウンロードされます。
PyPIの問題は解決しませんが、ビルドされたvirtualenvを開発者(またはデプロイメント)に渡すにはTerrariumを使用します。
terrarium を使用して、virtualenvをパッケージ化、圧縮、および保存します。それらをローカルに保存することもできます S3に保存する 。 GitHubのドキュメントから:
$ pip install terrarium
$ terrarium --target testenv --storage-dir /mnt/storage install requirements.txt
新しい環境を構築した後、テラリウムは環境をアーカイブして圧縮し、それをstorage-dirで指定された場所にコピーします。
同じstorage-dirを指定する同じ要件セットの後続のインストールでは、terrariumは/ mnt/storageから圧縮アーカイブをコピーして抽出します。
テラリウムでアーカイブに名前を付ける方法を正確に表示するには、次のコマンドを実行します。
$ terrarium key requirements.txt more_requirements.txt
x86_64-2.6-c33a239222ddb1f47fcff08f3ea1b5e1
私は最近 devpi を開発チームのVagrant構成にインストールして、パッケージキャッシュがホストのファイルシステムに存在するようにしました。これにより、各VMは、virtualenv/pipのインデックスURLとして使用する独自のdevpi-serverデーモンを持つことができます。VMが破棄されて再プロビジョニングされるとき、パッケージはホストのファイルシステム上にある限り、各開発者はそれらを1回ダウンロードして、ローカルキャッシュを構築します。
現在、Apacheによって提供されている単なるディレクトリであるプライベートパッケージ用の内部PyPiインデックスもあります。最終的に、それをdevpiプロキシサーバーにも変換するので、ビルドサーバーは、プライベートライブラリのホストに加えて、Python依存関係のパッケージキャッシュも維持します。これにより、開発環境、プロダクションデプロイメント、パブリックPyPiの間の追加のバッファ。
これは、これまでこれらの要件に対して私が見つけた最も堅牢なソリューションのようです。
David Woleverの pip2pi を見てください。 cronジョブを設定して、会社全体またはチーム全体で必要なパッケージのミラーを維持し、pipsを内部ミラーに向けることができます。