在 Python 开发中使用共享模块的正确方法是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17174992/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the proper way to work with shared modules in Python development?
提问by Steve Sawyer
I'm working toward adopting Python as part of my team's development tool suite. With the other languages/tools we use, we develop many reusable functions and classes that are specific to the work we do. This standardizes the way we do things and saves a lot of wheel re-inventing.
我正在努力采用 Python 作为我团队开发工具套件的一部分。使用我们使用的其他语言/工具，我们开发了许多特定于我们所做工作的可重用函数和类。这标准化了我们做事的方式，并节省了大量重新发明轮子的工作。
I can't seem to find any examples of how this is usually handled with Python. Right now I have a development folder on a local drive, with multiple project folders below that, and an additional "common" folder containing packages and modules with re-usable classes and functions. These "common" modules are imported by modules within multiple projects.
我似乎找不到任何关于通常如何使用 Python 处理的示例。现在我在本地驱动器上有一个 development 文件夹，下面有多个项目文件夹，还有一个额外的“common”文件夹，其中包含具有可重用类和函数的包和模块。这些“公共”模块由多个项目中的模块导入。
Development/
Common/
Package_a/
Package_b/
Project1/
Package1_1/
Package1_2/
Project2/
Package2_1/
Package2_2/
In trying to learn how to distribute a Python application, it seems that there is an assumption that all referenced packages are below the top-level project folder, not collateral to it. 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. However, that also raises questions re distribution.
在尝试学习如何分发 Python 应用程序时，似乎假设所有引用的包都在顶级项目文件夹之下，而不是附属于它。我还想到，也许正确的方法是在单独的项目中开发通用/框架模块，并在测试后通过安装到 site-packages 文件夹将它们部署到每个开发人员的环境中。然而，这也引发了重新分配的问题。
Can anyone shed light on this, or point me to a resource that discusses this issue?
任何人都可以对此有所了解，或者向我指出讨论此问题的资源？
回答by Cameron Sparr
I think that this is the best reference for creating a distributable python package:
我认为这是创建可分发 python 包的最佳参考：
link removed as it leads to a hacked site.
链接被删除，因为它会导致一个被黑的网站。
also, don't feel that you need to nest everything under a single directory. You can do things like
另外，不要觉得您需要将所有内容都嵌套在一个目录下。你可以做这样的事情
platform/
core/
coremodule
api/
apimodule
and then do things like from platform.core import coremodule, etc.
然后做诸如此类的事情from platform.core import coremodule。
回答by Ethan Coon
The must-read-first on this kind of stuff is here:
此类内容的必读内容如下：
What is the best project structure for a Python application?
in case you haven't seen it (and follow the link in the second answer).
如果您还没有看到它（并按照第二个答案中的链接）。
The key is that each major package be importable as if "." was the top level directory, which means that it will also work correctly when installed in a site-packages. What this implies is that major packages should all be flat within the top directory, as in:
关键是每个主要包都可以像“.”一样导入。是顶级目录，这意味着它在安装在站点包中时也能正常工作。这意味着主要包应该都在顶级目录中，如下所示：
myproject-0.1/
myproject/
framework/
packageA/
sub_package_in_A/
module.py
packageB/
...
Then both you (within your other packages) and your users can import as:
然后你（在你的其他包中）和你的用户都可以导入为：
import myproject
import packageA.sub_package_in_A.module
etc
等等
Which means you should think hard about @MattAnderson's comment, but if you want it to appear as a separately-distributable package, it needs to be in the top directory.
这意味着您应该仔细考虑@MattAnderson 的评论，但是如果您希望它作为一个单独分发的包出现，它需要位于顶级目录中。
Note this doesn't stop you (or your users) from doing an:
请注意，这不会阻止您（或您的用户）执行以下操作：
import packageA.sub_package_in_A as sub_package_in_A
but it does stop you from allowing:
但它确实阻止您允许：
import sub_package_in_A
directly.
直接地。
回答by Aya
...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.pathby default, which makes it very convenient to import modules and packages below that directory.
这主要是因为sys.path默认情况下当前工作目录是第一个条目，这使得导入该目录下的模块和包非常方便。
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.
我还想到，也许正确的方法是在单独的项目中开发通用/框架模块，并在测试后通过安装到 site-packages 文件夹将它们部署到每个开发人员的环境中。
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 hacksto 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.
这是事情会变得更复杂的地方，但前提是您计划独立于使用它们的项目发布库，和/或让多个项目安装程序共享相同的库。就是这样，看看distutils。
If not, you can simply employ the same relative path hacks used in development to ensure you project works "out of the box".
如果没有，您可以简单地使用开发中使用的相同相对路径技巧来确保您的项目“开箱即用”。
回答by robjohncox
If you have common code that you want to share across multiple projects, it may be worth thinking about storing this code in a physically separate project, which is then imported as a dependency into your other projects. This is easily achieved if you host your common code project in github or bitbucket, where you can use pip to install it in any other project. This approach not only helps you to easily share common code across multiple projects, but it also helps protect you from inadvertently creating bad dependencies (i.e. those directed from your common code to your non common code).
如果您有想要在多个项目之间共享的公共代码，可能值得考虑将此代码存储在一个物理上独立的项目中，然后将其作为依赖项导入到您的其他项目中。如果您在 github 或 bitbucket 中托管您的公共代码项目，这很容易实现，您可以在其中使用 pip 将其安装在任何其他项目中。这种方法不仅可以帮助您轻松地跨多个项目共享公共代码，而且还有助于防止您无意中创建不良依赖项（即从公共代码定向到非公共代码的依赖项）。
The link below provides a good introduction to using pip and virtualenv to manage dependencies, definitely worth a read if you and your team are fairly new to working with python as this is a very common toolchain used for just this kind of problem:
下面的链接很好地介绍了使用 pip 和 virtualenv 管理依赖项，如果您和您的团队对使用 python 相当陌生，那么绝对值得一读，因为这是用于此类问题的非常常见的工具链：
http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
And the link below shows you how to pull in dependencies from github using pip:
下面的链接向您展示了如何使用 pip 从 github 中提取依赖项：
How to use Python Pip install software, to pull packages from Github?
