12

RPM としてパッケージ化およびデプロイする必要があるスクリプト/モジュールで構成される Python アプリケーションがいくつかあります。

ややこしいのは、各アプリケーションをすべての Python モジュールの依存関係と共に配布する必要があることです。これらは、システム全体にインストールされているものよりも優先して使用する必要があります。

これらの RPM の一部のターゲット ホストは、ネットワーク アクセスが制限されているため、RPM には、デプロイ時に何かをダウンロードするのではなく、アプリの実行に必要なすべてが含まれている必要があります。

virtualenvのパッケージ化と配布を見てきましたが、virtualenvの再配置は十分にサポートされていないようです。

zc.buildoutを見てきましたが、ドキュメントが不足していることがわかりました。開発中に依存関係をダウンロードする方法はわかりましたが、より大きなアプリケーションの一部としてそれらを配布する方法はわかりませんでした。異なるアプリが同じモジュールの異なるバージョンを必要とする可能性があるため、これらをシステム全体にインストールしないでください。

もう 1 つの問題点は、アプリ内のすべての Python スクリプトを変更して、開発中と展開後に別の sys.path を使用する必要があることです。これを回避する明確な方法がわかりませんでした。

これを達成するための最善の方法についての提案はありますか? 開発者の観点からのワークフローの理想的な要約は次のようになります。

  1. アプリケーションのソースをダウンロード
  2. スクリプトを実行して、存在しない場合は特定のモジュールの依存関係を取得します (おそらくpipを使用)
  3. スクリプトを実行して Python アプリをビルドし、それとダウンロードしたすべての依存関係を RPM にパッケージ化します。

最終的な RPM は、ネットワーク アクセスがなく、Python インタープリターのみがインストールされているホストでインストールおよび実行できる必要があります。

4

1 に答える 1

1

私はそれを2つの別々の問題と見なします。

  1. 開発者のために繰り返しインストール/ビルド システムが必要です。

  2. インストーラービルダーが必要です。

Buildout (または pip、おそらく追加のスクリプトと組み合わせて) は、最初の問題を処理できます。基本的には、「新しいラップトップでプロジェクトを開発する準備を整える方法」です。理想的には、言うだけpython bootstrap.py;bin/buildoutで準備が整います (pip/virtualenv と同じ)。

繰り返し可能なビルドができたので、それをインストーラーのベースとして使用できます。Handiest は、この目的のためだけに使用するクリーンな仮想マシンです。たとえば、Virtualbox / vagrant。virtualbox をセットアップし、そこに適切な依存関係をインストールするスクリプトを作成します。

インストーラー ビルダー スクリプトは、virtualbox 内でプロジェクトの新しいチェックアウトを作成し、インストーラーに配置する場所 (/opt/yourprojectたとえば、) で繰り返し可能なビルドを実行できます。

次に、FPMを使用して実際のパッケージ (.deb、.rpm など) を作成します。必要な依存関係を伝える FPM オプションを渡します。これにより、それらの依存関係がインストールされていることを常に確認できます。(注: これらは、memcached や postgres などの OS レベルの依存関係です。Python の依存関係は、pip または buildout で処理する必要があります)。

大きな問題をこれら 2 つの小さな問題に分割すると、両方が別々に攻撃される可能性があります。

于 2013-09-02T12:36:42.363 に答える