我认为正确的答案是“否”,但你会发现很多发行版本都安装了测试。测试不应该被安装,而应该包含在源分发中。在我的看法中,在理想的世界中,安装软件包的测试应该是软件包管理器(pip)执行的任务,而site-packages
目录不应该被测试源代码污染。
最近我研究了这个话题,并从各种来源收集了信息,找到了几种包含库源代码和测试的分发目录/包层次结构。大部分这样的结构似乎已经过时,并且它们是为了解决当时较旧的分发系统功能不完整的尝试而发明的。不幸的是,许多在线资源(较旧的博客文章/文档)仍然在宣传过时的方法,因此在在线搜索中很容易找到过时的分发教程。
假设你有一个名为“my_lib”的库,你想构建你的分发源代码的结构。我将展示两种流行且看起来过时的构建分发的方式,以及我发现的最通用的第三种方式。第三种方法也可能已经过时,但这是我发布这个答案时所知道的最好的方法。;-)
方法一
(有意或无意地)安装测试的发行版通常使用此方法。
层次结构
+- my_lib
| +- __init__.py
| +- source1.py
| +- source2.py
| +- tests
| +- __init__.py
| +- test_1.py
| +- test_2.py
+- setup.py
第二种方法
测试未安装,但应通过 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() 在 setup.py 中的调用
from setuptools import setup, find_packages
setup(
...
packages=find_packages('src'),
package_dir={'': 'src'},
...
)
MANIFEST.in
recursive-include tests *.py
测试将不会被安装,但是它们将通过我们的MANIFEST.in
包含在源分发中。
对于方法#3,您拥有一个src
目录,通常只包含一个作为库根的单个包。将my_lib
包放入src
目录中(目录而不是包,因此您不需要src/__init__.py
)具有以下优点:
numpy
scipy
pandas
sympy
blaze
numba
skimage
都已经安装了测试文件在 site-packages 中,这也值得一提。 - endolithimport test
时得到的是基于安装顺序之类的随机命名? - scannynumpy.linalg.tests
,numpy.fft.tests
,scipy.fftpack.tests
,panda.tests
,sympy.integrals.tests
,skimage.segmentation.tests
,blaze.tests
,numba.tests
等测试。 - endolith