Pythonで重要なエンドユーザーデスクトップ（Webではない）アプリケーションを開発したいとします。プロジェクトのフォルダ階層を構造化するための最良の方法は何ですか？
望ましい機能は、メンテナンスのしやすさ、IDEの使いやすさ、ソース管理の分岐/マージへの適合性、およびインストールパッケージの簡単な生成です。
特に：
あまり問題ではありません。あなたを幸せにするものは何でもうまくいくでしょう。Pythonプロジェクトは単純である可能性があるため、ばかげたルールはそれほど多くありません。
/scriptsまたは/binその種のコマンドラインインターフェイスのもの/testsあなたのテストのために/libC言語ライブラリ用/docほとんどのドキュメント/apidocEpydocで生成されたAPIドキュメント用。また、最上位ディレクトリには、README、Configなどを含めることができます。
/src難しい選択は、ツリーを使用するかどうかです。Pythonには、、、およびJavaやCのよう/srcに区別がありません。/lib/bin
トップレベル/srcディレクトリは無意味と見なされる人もいるため、トップレベルディレクトリをアプリケーションのトップレベルアーキテクチャにすることができます。
/foo/bar/bazこれらすべてを「name-of-my-product」ディレクトリに配置することをお勧めします。したがって、という名前のアプリケーションを作成している場合、quuxこれらすべてのものを含むディレクトリはという名前になり /quuxます。
したがって、別のプロジェクトには、モジュール を再利用するPYTHONPATHことを含めることができます。/path/to/quux/fooQUUX.foo
私の場合、Komodo Editを使用しているため、IDEcuftは単一の.KPFファイルです。私は実際にそれをトップレベルの/quuxディレクトリに置き、SVNへの追加を省略しています。
PythonプロジェクトのJean-Paul Calderoneのファイルシステム構造によると：
Project/
|-- bin/
| |-- project
|
|-- project/
| |-- test/
| | |-- __init__.py
| | |-- test_main.py
| |
| |-- __init__.py
| |-- main.py
|
|-- setup.py
|-- README
Jean-Paul Calderone によるこのブログ投稿は、一般的に Freenode の #python で回答として与えられます。
Python プロジェクトのファイルシステム構造
行う：
- ディレクトリにプロジェクトに関連する名前を付けます。たとえば、プロジェクトの名前が「Twisted」の場合、そのソース ファイルの最上位ディレクトリに名前を付けます
Twisted。リリースするときは、バージョン番号のサフィックスを含める必要があります:Twisted-2.5.- ディレクトリ
Twisted/binを作成し、実行可能ファイルがある場合はそこに配置します。.pyPython ソース ファイルであっても、拡張子を付けないでください。プロジェクトの別の場所で定義されたメイン関数のインポートと呼び出し以外のコードをそれらに入れないでください。(ちょっとしわ: Windows では、インタープリターはファイル拡張子によって選択されるため、Windows ユーザーは実際には .py 拡張子を必要とします。そのため、Windows 用にパッケージ化するときに、拡張子を追加することをお勧めします。残念ながら、簡単な distutils のトリックはありません。私はこのプロセスを自動化することを知っています. POSIX では .py 拡張子はただの疣贅ですが、Windows ではその欠如は実際のバグであることを考慮すると、ユーザーベースに Windows ユーザーが含まれている場合は、.py のみを選択することをお勧めします。どこでも拡張可能です。)- プロジェクトが単一の Python ソース ファイルとして表現できる場合は、それをディレクトリに配置し、プロジェクトに関連する名前を付けます。たとえば、
Twisted/twisted.py. 複数のソース ファイルが必要な場合は、代わりにパッケージを作成し (Twisted/twisted/、空のTwisted/twisted/__init__.py)、その中にソース ファイルを配置します。たとえば、Twisted/twisted/internet.py.- 単体テストをパッケージのサブパッケージに入れます (注 - これは、上記の単一の Python ソース ファイル オプションがトリックであることを意味します。単体テストには、常に少なくとも 1 つの他のファイルが必要です)。たとえば、
Twisted/twisted/test/. もちろん、 でパッケージ化しTwisted/twisted/test/__init__.pyます。のようなファイルにテストを配置しますTwisted/twisted/test/test_internet.py。- 気分がよければ、それぞれソフトウェアの説明とインストールに
Twisted/READMEとを追加してください。Twisted/setup.pyしてはいけないこと:
srcまたはという名前のディレクトリにソースを置きますlib。これにより、インストールせずに実行するのが難しくなります。- テストを Python パッケージの外に置きます。これにより、インストールされたバージョンに対してテストを実行することが難しくなります。
- のみを持つパッケージを作成し、
__init__.pyすべてのコードを に入れます__init__.py。パッケージの代わりにモジュールを作成するだけで、より簡単になります。- ユーザーがモジュールまたはパッケージを含むディレクトリをインポート パスに追加しなくても (PYTHONPATH またはその他のメカニズムを介して)、Python がモジュールまたはパッケージをインポートできるようにするための魔法のハックを思いつくようにしてください。すべてのケースを正しく処理できるわけではなく、ソフトウェアが自分の環境で動作しない場合、ユーザーは怒ります。
Open Sourcing a Python Project the Right Way を確認してください。
その優れた記事のプロジェクト レイアウトの部分を抜粋してみましょう。
プロジェクトをセットアップするときは、レイアウト (またはディレクトリ構造) を正しく設定することが重要です。賢明なレイアウトとは、潜在的な貢献者がコードの断片を探すのに永遠に費やす必要がないことを意味します。ファイルの場所は直感的です。私たちは既存のプロジェクトを扱っているので、おそらくいくつかのものを移動する必要があるでしょう.
上から始めましょう。ほとんどのプロジェクトには、いくつかの最上位ファイル (setup.py、README.md、requirements.txt など) があります。次に、すべてのプロジェクトに必要な 3 つのディレクトリがあります。
- プロジェクト ドキュメントを含む docs ディレクトリ
- 実際の Python パッケージを格納する、プロジェクトの名前が付けられたディレクトリ
- 2 つの場所のいずれかにあるテスト ディレクトリ
- テスト コードとリソースを含むパッケージ ディレクトリの下
- スタンドアロンの最上位ディレクトリとして ファイルをどのように整理するかをよりよく理解するために、私のプロジェクトの 1 つであるサンドマンのレイアウトの簡単なスナップショットを次に示します。
$ pwd ~/code/sandman $ tree . |- LICENSE |- README.md |- TODO.md |- docs | |-- conf.py | |-- generated | |-- index.rst | |-- installation.rst | |-- modules.rst | |-- quickstart.rst | |-- sandman.rst |- requirements.txt |- sandman | |-- __init__.py | |-- exception.py | |-- model.py | |-- sandman.py | |-- test | |-- models.py | |-- test_sandman.py |- setup.pyご覧のとおり、いくつかの最上位ファイル、docs ディレクトリ (生成されるのは、生成されたドキュメントを sphinx が配置する空のディレクトリです)、sandman ディレクトリ、および sandman の下の test ディレクトリがあります。
「Python Packaging Authority」にはサンプルプロジェクトがあります。
https://github.com/pypa/sampleproject
これは、プロジェクトのパッケージ化と配布に関する Python Packaging User Guide のチュートリアルを支援するために存在するサンプル プロジェクトです。
python_boilerplateテンプレートを使用してプロジェクトを開始してみてください。これは大部分がベスト プラクティス (たとえば、ここにあるもの) に従いますが、ある時点でプロジェクトを複数の卵に分割することをいとわない場合に適しています (信じてください。最も単純なプロジェクト以外であれば、そうするでしょう。一般的な状況は、他の人のライブラリのローカルで変更されたバージョンを使用する必要がある場合です)。
ソースはどこに置く？
PROJECT_ROOT/src/<egg_name>ます。アプリケーションの起動スクリプトはどこに置きますか?
entry_point、卵の 1 つにアプリケーションの起動スクリプトを登録することです。IDE プロジェクトの粗悪品をどこに置きますか?
PROJECT_ROOT/.<something>それらの多くは、プロジェクトのルートに自分のものを保持していますが、これは問題ありません。ユニット/受け入れテストはどこに配置しますか?
PROJECT_ROOT/src/<egg_name>/testsディレクトリに保持されます。私は個人的にそれらを実行するために使用することを好みpy.testます。設定ファイルなどの Python 以外のデータはどこに置きますか?
pkg_resourcesのパッケージを介してsetuptools、または Python 3.7 以降importlib.resourcesでは標準ライブラリのモジュールを介して使用できます。PROJECT_ROOT/config. 展開には、さまざまなオプションがあります。Windows では%APP_DATA%/<app-name>/config、Linux では 、/etc/<app-name>またはを使用できます/opt/<app-name>/config。PROJECT_ROOT/var開発中はそれらを保持し、 /varLinux の展開中は保持したいと思います。PROJECT_ROOT/src/<egg_name>/nativeドキュメンテーションは、通常、PROJECT_ROOT/docまたはPROJECT_ROOT/src/<egg_name>/doc(これは、いくつかの卵を別個の大きなプロジェクトとみなすかどうかによって異なります) に入ります。追加の設定は、 や などのファイルにPROJECT_ROOT/buildout.cfgありPROJECT_ROOT/setup.cfgます。
私の経験では、それは単なる反復の問題です。どこにでもデータとコードを配置できます。とにかく、あなたは間違っている可能性があります。しかし、物事がどのように形作られるかを正確に把握すると、これらの種類の推測を行うのにはるかに適した立場になります.
拡張ソースに関しては、trunk の下に Code ディレクトリがあり、Python 用のディレクトリと他のさまざまな言語用のディレクトリが含まれています。個人的には、次回は拡張コードを独自のリポジトリに入れてみようと思っています。
そうは言っても、最初のポイントに戻ります。あまり大げさなことをしないでください。自分に合うと思われる場所に置いてください。機能しないものを見つけた場合は、変更できます (変更する必要があります)。
Python 以外のデータは、 setuptoolspackage_dataのサポートを使用して Python モジュール内にバンドルするのが最適です。私が強くお勧めすることの 1 つは、名前空間パッケージを使用して、複数のプロジェクトで使用できる共有名前空間を作成することです。これは、パッケージを配置する(そして共有名前空間を持つことができる) Java の規則によく似ています。com.yourcompany.yourprojectcom.yourcompany.utils
再分岐とマージ。十分に優れたソース管理システムを使用すれば、名前を変更してもマージを処理できます。Bazaarはこれが特に得意です。
ここでの他のいくつかの回答とは対照的に、私はsrcトップレベルのディレクトリを持つことについて+1です（ディレクトリと一緒docにtest）。ドキュメント ディレクトリ ツリーの特定の規則は、使用しているものによって異なります。たとえば、 Sphinxには、クイックスタート ツールがサポートする独自の規則があります。
setuptools と pkg_resources を活用してください。これにより、他のプロジェクトがコードの特定のバージョンに依存しやすくなります (また、 を使用している場合は、複数のバージョンが異なる非コード ファイルと共に同時にインストールされますpackage_data)。