在运行setuptools测试时访问包中的`__init __。py`中定义的名称

Question

我已经将模块代码直接放在包__init__.py中，即使对于最终成为唯一文件的简单包也是如此。

所以我有一堆看起来像这样的软件包（尽管它们并非都被称为pants :)。

+ pants/
\-- __init__.py
\-- setup.py
\-- README.txt
\--+ test/
   \-- __init__.py

我开始这样做是因为它允许我将代码放在一个单独的（并且，关键的，可单独版本化的）目录中，并使其工作方式与将软件包放在单个{{1 }}。我将这些保存在我的dev python lib目录中，我在处理这些事情时已将其添加到module.py中。每个包都是一个单独的git repo。

修改...

与典型的Python包布局相比，如Radomir的answer中所示，此设置使我无需将每个包的目录添加到我的PYTHONPATH中。

... /修改

这已经很好了，但我遇到了这个（有点模糊）的问题：

在程序包目录中运行测试时，程序包本身（即$PYTHONPATH中的代码）不能保证在__init__.py上。这在我的典型环境下不是问题，但如果有人下载sys.path并将源代码分发的tarball提取到目录中，并运行pants-4.6.tgz，则cd包python setup.py test 1}}本身通常不在他们的pants。

我发现这很奇怪，因为我希望sys.path从被测试包的父目录运行测试。然而，无论出于何种原因，它都没有这样做，我想因为通常你不会这样包装东西。

相对导入不起作用，因为setuptools是顶级包，已被发现为test的当前目录组件的子目录。

我希望避免将代码移到单独的文件中并将其公用名称导入sys.path。主要是因为对于一个简单的模块而言，这似乎是毫无意义的混乱。

我可以从__init__.py内明确地将父目录添加到sys.path，但不愿意。首先，至少在理论上，这可能会失败，例如，如果有人决定从他们的文件系统的根目录运行测试（可能是Windows驱动器）。但大多数情况下，它只是让人感到操控。

有更好的方法吗？

将代码放入setup.py？

是否被视为特别糟糕的形式？

Answer 1

我认为打包python程序的标准方法更像是这样：

\-- setup.py
\-- README.txt
\--+ pants/
   \-- __init__.py
   \-- __main__.py
   ...
\--+ tests/
   \-- __init__.py
   ...
\--+ some_dependency_you_need/
   ...

然后你就避免了这个问题。