8

共通のモジュールを共有するPythonプロジェクトがいくつかあります。これまで、私は...ええと...共通コードの複数のコピーを保持し、手動で同期してきました。しかし、私は明らかに何か他のことをしたいと思っています。

zc.Buildoutがおそらく私が必要としているものであるかのように、今私には見えます。私がすべきことは、システムの再利用可能な各コンポーネントを別々の卵に入れ、ビルドアウトを使用してそれらをプロジェクトにアセンブルすることだと思います。

また、特定のモジュールについては、ユニットテストを別のパッケージまたはeggに入れて、すべてのプロジェクトにコンポーネントのユニットテストのコピーをインストールしないようにする必要があると考えています。ライブラリが使用されているだけではなく、ライブラリが開発されている場所でのみ単体テストを実行したいと思います。

だから多分私はこのようなものが欲しい

projects
  lib1
    tests
    code
  lib2
    tests
    code
  app1
    tests 
    appcode
  app2
    tests
    appcode

等

app1とapp2の両方が独自のコードとテストを備えた独立したアプリケーションであるが、lib1とlib2の両方を含み使用している場合。そして、lib1 / test、lib1 / code、lib2 / test、lib2code、app1、app2は別々の卵です。これは正しいですか？

しかし、今は混乱しています。app1を開発するとき、ビルドアウトでlib1、lib2、およびapp1のコピーを、app1の下に直接配置するのではなく、別の作業ディレクトリにプルする必要があると思います。しかし、これは私のSVNソース管理でどのように機能しますか？作業ディレクトリがビルドアウトを使用して動的に構築されている場合、変更をリポジトリにチェックバックできるライブSVNディレクトリにすることはできませんか？

ビルドアウトがどのように使用されるのか誤解しましたか？まったく別のアプローチをとったほうがいいでしょうか？プロジェクト間でソース管理とモジュール再利用をどのように組み合わせますか？

更新：現在この質問に回答してくれた2人に感謝します。私はこれでもっと実験しています。

4

4 に答える 4

5

テストをコードから分離しないでください。2つを密接に保つ必要があります。テストがそれほど多くのディスクスペースやメモリを消費するわけではありません。また、テストはライブラリユーザーにとって非常に有益です。

ライブラリパッケージの場合、テストの実行を容易にするために、パッケージにファイルを含めますbuildout.cfg。bootstrap.pyたとえば、plone.reloadパッケージを参照してください。zc.recipe.testrunnerパーツを使用して、テストを自動検出して実行するテストスクリプトを作成する方法に注意してください。このようにして、ライブラリパッケージが常にテストされていることを確認できます。

次に、アプリパッケージは、統合とアプリケーション固有のコードをテストするだけで済みます。繰り返しになりますが、パッケージ自体にテストを含めます。コードで作業するときにテストを忘れないようにします。zc.recipe.testrunnerビルドアウトのパーツを使用して、これらを検出して実行します。

最後になりましたが、mr.developerを使用してパッケージを管理してください。mr.developerを使用すると、パッケージを作業としてチェックアウトしたり、コードで作業する必要がない場合はリリースされたバージョンに依存したりできます。大規模なプロジェクトには多くの依存関係があり、その多くはコードを微調整する必要がありません。mr.developerを使用すると、ソースコードを自由にプルして、開発エッグに変えることができます。そのようなときまで、そのコードをリリースして、チェックアウトを再度閉じることができます。

そのようなプロジェクトビルドアウトの実際の例を見るには、 Ploneコア開発ビルドアウト以上のものを探す必要はありません。

このsources.cfgファイルには、さまざまなパッケージのSCMの場所の長いリストが含まれていますが、作業する予定のパッケージを明示的にアクティブ化するまで、通常リリースされているバージョンのeggが使用されます。checkouts.cfgデフォルトでチェックアウトされているすべてのパッケージを一覧表示します。これらのパッケージには、Ploneの次のバージョンの一部となる変更があり、まだリリースされていません。Ploneで作業している場合は、これらの変更を無視できないため、これらを回避する必要があります。そしてtesting.cfg、Ploneをテストしたい場合にテストする必要のあるすべてのパッケージをリストします。これは大きなリストです。

Ploneのソースはさまざまな場所から来ていることに注意してください。buildoutとmr.developerを使用してパッケージを管理し始めると、どこからでも自由にソースコードをプルできます。

于 2011-10-01T14:15:43.133 に答える
2

私は次の構造を非常に効果的に使用しました。SVNで。

Lib1/
   branches/
   tags/
   trunk/
     lib1/
     tests/
     setup.py
Lib2
   branches/
   tags/
   trunk/
     lib2/
     tests/
     setup.py
App1
   branches/
   tags/
   trunk/
     app1/
     tests/
     setup.py
App2
   branches/
   tags/
   trunk/
     app2/
     tests/
     setup.py

次に、トランクまたはブランチからチェックアウトして、次のように開発ワークスペース（eclipse / pydevを使用）を作成します。

Lib1/
   lib1/
   tests/
   setup.py
Lib2/
   lib2/
   tests/
   setup.py
App1/
   app1/
   tests/
   setup.py
App2/
   app2/
   tests/
   setup.py

次に、Eclipseプロジェクトの依存関係のセットアップPythonパスを使用します。これは、Eclipseコード補完でうまく機能します。setup.pyも機能しますが、複数のワークスペースを持つことはサポートされていません。

デプロイには、次の構造の単一のzipを作成するために使用します。

App1/
   lib1-1.1.0-py2.5.egg/
   lib2-1.1.0-py2.5.egg/
   app1/
   sitecustomize.py

App2/
   lib1-1.2.0-py2.5.egg/
   lib2-1.2.0-py2.5.egg/
   app2/
   sitecustomize.py

アプリの複数のバージョンをサポートしたいので、セットアップインストールを使用しません。また、ランタイム環境をある程度制御できるので、Pythonをデプロイメントと一緒にパッケージ化しませんが、Pythonをデプロイメントパッケージに簡単に追加できるはずです。それが必要です。

于 2008-10-12T04:37:08.237 に答える
2

これが、サイトモジュールがある理由です。sys.pathすべてのパッケージとモジュールを含めるように内部を設定します

  • lib/site-packages-- ディレクトリ、卵、.pthファイルを含む。
  • PYTHONPATH

このようにして、ライブラリの作業コピーが 1 つだけ存在します。

これを利用する方法は無限にあります。ここに2つあります。

  1. 各ライブラリに、setup.pyライブラリを適切にデプロイする a を記述します。変更を行うときは、 を実行してsvn up変更を収集し、 を実行しpython setup.py installて、すべてのアプリケーションが共有する 1 つの作業コピーをデプロイします。

  2. PYTHONPATH各アプリでは、環境変数にあるものに依存します。projects/lib1とprojects/lib2が を獲得したことを確認してくださいPYTHONPATH。各アプリは、さまざまなライブラリの 1 つの作業コピーを共有します。

于 2008-10-11T19:22:32.053 に答える
1

私は各アプリケーションとライブラリを卵と見なし、SVN でのレイアウトに関して既に示した例の 1 つを使用します。本当に、VCS の終わりは問題にならないはずです。

次に、各アプリケーション/ライブラリまたは組み合わせをテストするために、virtualenv をセットアップし、setup.py 開発または実際にインストールして各パッケージをインストールします。Virtualenvwrapper は、次のようなことを簡単に実行できるため、これらの環境を管理するための便利なツールでもあります。

mkvirtualenv lib1-dev

そして後で：

workon lib1-dev

Virtualenv は PYTHONPATH を使用して、インストールされているパッケージをより細かく制御します。同様に、次のように create environment を使用できます。

virtualenv --no-site-packages some-env

また、実際のシステム サイト パッケージへの参照はすべて除外されます。ライブラリ/アプリケーションをテストできるだけでなく、インストールに正しい依存関係があることを確認できるため、これは役に立ちます。

于 2009-01-07T19:38:52.057 に答える