59

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

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

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

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

任何人都可以阐明这一点，或者指出我讨论这个问题的资源吗？

4

4 回答 4

17

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

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

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

下面的链接向您展示了如何使用 pip 从 github 中提取依赖项：

如何使用 Python Pip 安装软件，从 Github 拉包？

于 2013-06-18T18:45:09.713 回答
11

这类东西的必读先在这里：

Python 应用程序的最佳项目结构是什么？

如果您还没有看到它（并按照第二个答案中的链接进行操作）。

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

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

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

import myproject
import packageA.sub_package_in_A.module

ETC

这意味着您应该认真考虑@MattAnderson 的评论，但如果您希望它显示为可单独分发的包，则它需要位于顶层目录中。

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

import packageA.sub_package_in_A as sub_package_in_A

但它确实阻止你允许：

import sub_package_in_A

直接地。

于 2013-06-18T17:41:02.217 回答
3

我认为这是创建可分发 python 包的最佳参考：

链接被删除，因为它导致了一个被黑的网站。

另外，不要觉得您需要将所有内容嵌套在一个目录下。你可以做类似的事情

platform/
    core/
        coremodule
    api/
        apimodule

然后做类似的事情from platform.core import coremodule，等等。

于 2013-06-18T17:35:26.970 回答
3

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

That's mainly because the current working directory is the first entry in sys.path by default, which makes it very convenient to import modules and packages below that directory.

If you remove it, you can't even import stuff from the current working directory...

$ 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.

It's not really a major issue for development. If you're using version control, and all developers check out the source tree in the same structure, you can easily employ relative path hacks to ensure the code works correctly without having to mess around with environment variables or symbolic links.

However, that also raises questions re distribution.

This is where things can get a bit more complicated, but only if you're planning to release libraries independently of the projects which use them, and/or having multiple project installers share the same libraries. It that's the case, take a look at distutils.

If not, you can simply employ the same relative path hacks used in development to ensure you project works "out of the box".

于 2013-06-18T17:55:39.047 回答