在Python开发中，使用共享模块的正确方法是什么？

Question

我正在努力采用Python作为团队开发工具套件的一部分。使用我们使用的其他语言/工具，我们开发了许多特定于我们所做工作的可重用函数和类。这使我们做事的方式标准化，并节省了大量的车轮重新发明。

我似乎找不到任何关于通常使用Python处理这个问题的例子。现在，我在一个本地驱动器上有一个开发文件夹，下面有多个项目文件夹，还有一个附加的“common”文件夹，其中包含具有可重用类和函数的包和模块。这些“公共”模块由多个项目中的模块导入。

Development/
    Common/
        Package_a/
        Package_b/
    Project1/
        Package1_1/
        Package1_2/
    Project2/
        Package2_1/
        Package2_2/

在试图学习如何分发Python应用程序时，似乎有一个假设，即所有引用的包都在顶级项目文件夹下，而不是附属于它的。我还想到，也许正确的方法是在一个单独的项目中开发公共/框架模块，并在测试后通过安装到site packages文件夹将这些模块部署到每个开发人员的环境中。然而，这也引发了重新分配的问题。

有人能解释一下这个问题，或者给我指一个讨论这个问题的资源吗？

Answer 1

如果您有希望在多个项目中共享的公共代码，则可能需要考虑将此代码存储在物理上独立的项目中，然后将其作为依赖项导入到其他项目中。如果您将公共代码项目托管在github或bitbucket中，可以使用pip将其安装到任何其他项目中，那么这很容易实现。这种方法不仅可以帮助您轻松地跨多个项目共享公共代码，而且还可以帮助您避免无意中创建不好的依赖项（即那些从公共代码指向非公共代码的依赖项）。

下面的链接很好地介绍了如何使用pip和virtualenv来管理依赖项，如果您和您的团队对使用python还比较陌生，那么一定值得一读，因为这是一个非常常见的用于解决此类问题的工具链：

http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/

下面的链接显示了如何使用pip从github中拉入依赖项：

How to use Python Pip install software, to pull packages from Github?

Answer 2

这类东西的必读书目如下：

What is the best project structure for a Python application?

如果你还没看到（请按照第二个答案中的链接）。

关键是每个主要包都是可导入的，就好像“.”是顶级目录一样，这意味着它在站点包中安装时也将正常工作。这意味着主要的包都应该放在顶层目录中，如下所示：

myproject-0.1/
    myproject/
        framework/
    packageA/
        sub_package_in_A/
            module.py
    packageB/
        ...

然后，您（在其他包中）和您的用户都可以导入为：

import myproject
import packageA.sub_package_in_A.module

等

这意味着您应该仔细考虑@MattAnderson的评论，但是如果您希望它作为一个单独的可分发包出现，它需要在顶部目录中。

请注意，这不会阻止您（或您的用户）执行以下操作：

import packageA.sub_package_in_A as sub_package_in_A

但它确实阻止了你允许：

import sub_package_in_A

直接的。

Answer 3

...it seems that there is an assumption that all referenced packages are below the top-level project folder, not collateral to it.

这主要是因为默认情况下，当前工作目录是^{}中的第一个条目，这使得在该目录下导入模块和包非常方便。

如果你删除它，你甚至不能从当前工作目录导入内容。。。

$ touch foo.py
$ python
>>> import sys
>>> del sys.path[0]
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named foo

The thought also occurred to me that perhaps the correct approach is to develop common/framework modules in a separate project, and once tested, deploy those to each developer's environment by installing to the site-packages folder.

这对发展来说并不是什么大问题。如果您使用的是版本控制，并且所有开发人员都签出了同一结构中的源代码树，那么您可以轻松地使用relative path hacks来确保代码正常工作，而不必处理环境变量或符号链接。

However, that also raises questions re distribution.

这是事情可能变得更复杂的地方，但前提是您计划独立于使用它们的项目发布库，并且/或者让多个项目安装程序共享同一个库。就是这样，看看distutils。

如果没有，您可以简单地使用开发中使用的相同的相对路径黑客，以确保您的项目工作“开箱即用”。