6

Python パッケージとその中にコンパイルされたコンポーネントを含むプロジェクトがあります。現在のディレクトリ レイアウトは次のとおりです。

<project>
  foo/
  foo/__init__.py
  foo/...

  src/
  src/c_foo.c

  tests/
  tests/test_foo.py

  setup.py

プロジェクトがビルドされると、distutilsは仮想環境にbuild/lib追加またはインストールするディレクトリを作成します。PYTHONPATH結果の構造は次のとおりです。

<project>
  build/lib
  build/lib/foo/__init__.py
  build/lib/foo/c_foo.so

問題は、プロジェクト ルートから Python インタープリター セッションを開始したり、プロジェクト ルートからテストを実行したりすると、ビルドされたツリーではなくソース ツリーが取得されることです。

これに対するいくつかの既存の解決策が使用されていることがわかりました。

  1. Python ソースを別のディレクトリに配置します。lib/fooなどmodules/foo。これの欠点は、すべてのソース ファイルに追加のディレクトリ レベルが追加されることと、コンパイルされた拡張機能を持たず、したがってルート ディレクトリに python パッケージがあるプロジェクトとの不一致です。

  2. つまり、chdirPython インタープリターが (ビルド スクリプトまたは手動で) ソース パッケージを認識しないように、プロジェクト ルートの外 (例: tests/ ディレクトリ) に移動する必要があります。

  3. パッケージを別の名前 (foo-moduleまたは などfoo-lib) でルートに保存し、適切なpackage_dir={'foo':'lib-foo'}行を に追加しsetup.pyます。これは pt のバリエーションです。1 にディレクトリ階層の余分なレベルがなくても、ほとんど同じことだと思います。

  4. パッケージをルートに保持して使用しますがsetup.py build_ext --inplace、これによりソース ツリーが汚染されます。

どちらの場合も、ソース ツリーから直接コードを変更/実行できる単純な python プロジェクトに対して、オーバーヘッドが発生します。上記の長所と短所、およびプロジェクトで使用する特定の方法について、皆さんの考えをぜひお聞かせください。

4

1 に答える 1

1

ディストリビュート (以前の setuptools)developでターゲットを試してみることをお勧めします。

distributeがインストールされていることを確認してから、次のsetup.pyように変更します。

# the setuptools package name is still used
from setuptools import setup, Extension
...

次に、virtualenv を入力して実行しますdevelop。

% source ~/virt/bin/activate
(virt)% cd ~/project
(virt)% python setup.py develop

プロジェクト ルート内からテストを実行できる必要があり、その virtualenv をアクティブ化すると、パスに関係なく、そのプロジェクトのパッケージと拡張機能にアクセスできます。

% cd /tmp
% source ~/virt/bin/activate
(virt)% python -c 'import foo, c_foo; print foo, c_foo'

<module 'foo' from '/Users/user/project/foo/__init__.py'>
<module 'c_foo' from '/Users/user/project/c_foo.so'>
于 2011-05-26T22:50:30.773 に答える