私の意見では、正しい答えは NO ですが、テストをインストールするディストリビューションはかなり多くあります。テストはインストールするべきではありませんが、ソース配布に含める必要があります。私の意見では、理想的な世界では、インストールされたパッケージのテストはパッケージ マネージャー (pip) によって実行されるべきであり、site-packagesディレクトリはテスト ソースで汚染されるべきではありません。
私は最近このトピックを調査し、さまざまなソースから情報を収集し、ライブラリ ソースとテストの両方を含むディストリビューションのディレクトリ/パッケージ階層を構造化するいくつかの異なる方法を見つけました。これらの構造のほとんどは時代遅れのようで、当時の古いディストリビューション システムの不完全な機能セットを回避する試みとして考案されました。残念なことに、多くのオンライン ソース (古いブログ投稿/ドキュメント) がまだ古い方法を宣伝しているため、オンライン検索で古いディストリビューションのハウツー/チュートリアルを簡単に見つけることができます。
「my_lib」というライブラリがあり、ディストリビューションのソースを構造化したいとします。ディストリビューションを構築するための 2 つの一般的で一見時代遅れに見える方法と、最も用途が広いとわかった 3 つ目の方法を紹介します。3番目の方法も時代遅れかもしれませんが、この回答を投稿した時点で私が知っている最良の方法です。;-)
方法 1
(意図的にまたは意図せずに) テストをインストールするディストリビューションは、通常、この方法を使用します。
階層
+- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
| +- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
方法 2
テストはインストールされませんが、ファイルを通じてソース配布に含める必要がありMANIFEST.inます。
階層
+- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
+- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
方法＃3（私はこれが好きです。）
これは、方法 2 に少しひねりを加えたもの (ディレクトリ) とほとんど同じsrcです。
階層
+- src
| +- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
+- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
setup.py での setup() 呼び出し
from setuptools import setup, find_packages
setup(
...
packages=find_packages('src'),
package_dir={'': 'src'},
...
)
MANIFEST.in
recursive-include tests *.py
テストはインストールされませんが、.NET を通じてソース配布に含まれますMANIFEST.in。
方法 3 の場合、src通常、lib のルートである単一のパッケージのみを含むディレクトリがあります。パッケージmy_libをsrcディレクトリ (ディレクトリではなくパッケージなので、必要ありませんsrc/__init__.py) に配置すると、次の利点があります。