大きなPythonプロジェクトを複数のパッケージに分割する
私は中型のPythonプログラム（12 KLOC）を単一のPythonパッケージで構成され、複数のサブパッケージで構成されています：
proj/
setup.py
proj/
__init__.py
projfile1.py
subproj1/
__init__.py
subprojfile1.py
...
subproj2/
__init__.py
...
tests/
これらのサブパッケージのいくつかは自己完結型で、独自の名前空間に存在できることがわかります。
proj/
setup.py
proj/
__init__.py
projfile1.py
...
subproj1/
__init__.py
subprojfile1.py
...
subproj2/
__init__.py
...
tests/
サブパッケージを分割することで、プログラムの個別の部分間の依存関係を減らすことで、将来の複雑さを軽減できると考えています。
名前空間外のsubproj1インポートは、proj/の別のサブパッケージからのユーティリティ関数のみです。
Pythonプロジェクトに複数のトップレベルパッケージが適切ですか？このように編成されたプロジェクトはありますか？
プロジェクトを複数のPythonパッケージとして編成することの欠点は何ですか？
複数の最上位パッケージは原則として問題ありませんが、それらが適切な解決策になることはめったにありません。
ディレクトリ構造自体は、結合や複雑さについては何も述べていません。ディレクトリ構造x/a, x/b, x/cとa, b, cの違いは、単なるディレクトリです。デザインは同じです。
アプリケーションの場合、特にこのアプリケーションが組織の外部に配布されていない場合は、都合のよいことを何でもしてください。複数のトップレベルパッケージが便利である場合は、そのプロジェクトレイアウトを使用してください。
他の人が使用するコードについては、もっと配慮する必要があります。問題は、ディレクトリレイアウトがPythonコード内のモジュール/パッケージに対応していることです。名前の衝突を解決する方法はないため、モジュールには適度に一意の名前を選択する必要があります。最上位のutilモジュールは1つだけです。そのため、すべてのモジュールの名前空間をプロジェクトの名前で付けることを強くお勧めします。Python/ PyPIでは、このモジュールがpip-インストール可能なパッケージ、これは非常に賢明な規則です。
ディレクトリ構造がカップリングを促進する1つの詳細は、共有testsディレクトリです。多くの場合、各パッケージのテストは、各ディレクトリ内に配置することをお勧めします。つまり、aのテストはtests/aではなくa/testで行われます。