Python 3：安装自己的和第 3 方包的好位置？答案

【问题标题】：Python 3: Good location(s) to install own and 3rd party packages?Python 3：安装自己的和第 3 方包的好位置？
【发布时间】：2012-03-08 16:47:32
【问题描述】：

对于 Python 3.x：

我想获得有关最佳目录的建议，在该目录中可以找到我想在多个项目（以及任何相关因素）中使用的模块。我知道 import 语句和 PYTHONPATH，以及使任何位置“工作”的各种方法，但我想符合标准做法。

所以：

我应该将我的模块放在“Pythonxx\Lib\site-packages”的包中吗？
site-packages 目录是否得到特殊处理，或者它与模块的其他可能位置没有什么不同？我对它是否有特殊的“.pth”和/或__init__.py 行为感到困惑。
约定在多大程度上受 distutils 所做的事情的影响，这似乎还没有真正为 Python 3 做好准备……这是否意味着我应该关注其他一些约定？
我该怎么做：http://docs.python.org/py3k/install/index.html 其中“安装工作方式”似乎声称（在表格中）“站点包”与 Windows 无关，尽管我看到一个空站点 -我的 Windows Python 3.1 安装中的 packages 目录。

-- 谢谢！

【问题讨论】：

嗯，我看到前两个答案与如何部署包（virtualenv 和 setup.py）有关。我的案例仅适用于在单个桌面上工作，我可以在其中手动放置常用模块，并可能手动调整路径而无需“部署”本身。也许可以说服我更正式地做事，但目前为这些文件创建安装似乎有点过头了。
您是否打算接受答案（请参阅每个答案左侧的大勾号）？如果没有，请告诉我们您需要哪些额外帮助。

标签： python installation package

【解决方案1】：

是的——但是让你的 setup.py 来做吧
否
为什么你认为有问题？
文档需要修复。默认的 Python 安装目录是 C:\PythonXY，而不是 C:\Python。默认包安装目录为 C:\PythonXY\Lib\site-packages。

【讨论】：

1.显然 setup.py 是为某些包创建部署的一部分。我不想部署本身...我已对问题添加了评论。
2.好的 3. 好吧，我很难辨别安装软件的当前状态，以及我的“非正式”系统范围的软件包是否应该模仿什么安装软件，或者做一些不同的事情来避开它/他们的方式. 4. 或者也许是“C:\PythonXY\site-packages”？
setup.py 是关于开发人员设置用于分发/部署的模型/包的全部内容。最后阶段是当您通过执行....\python setup.py install 安装模块/等时。如果它是您自己的模块/包，请像开发人员一样。在任何情况下，都不要随意将一堆文件复制到站点包中。
在部署阶段，我了解正确部署的基本原理（尽管我很难从许多文档页面中辨别出哪些部署工具处于 Python 3 的准备状态）。然而，有问题的情况更像是这样——我希望公共模块仍然是可开发的。假设我有项目 A、B 和 C 正在开发中，并且都调用公共模块“myutils.py”，该模块也在根据 A、B 和 C 中确定的不断变化的需求进行修订。是否有一个合适的位置来定位 myutils.py ?也许 site-packages 是完全错误的地方，这很公平。
关于 myutils.py：在您的开发环境中对其进行单元测试。当您满意它满足要求时，发布一个新版本并安装它。然后测试你的 a、b、c 的开发版本（请不要大写）。

【解决方案2】：

您可能希望考虑设置virtualenv，这是捆绑一组模块以供跨项目和平台使用的标准方式。

【讨论】：

我很欣赏这个回复，但是......我对部署（目前）不感兴趣，只是在单个桌面机器上的多个项目上使用相同的代码。通过阅读 pypi 文档页面，virtualenv 看起来更适合涉及部署到服务器等的用例，所以虽然我听说过 virtualenv，但它似乎对手头的问题没有帮助。

【解决方案3】：

巧合的是，今天是我提出这个问题的周年纪念日。尽管受访者试图提供帮助，但我最终对这个问题进行了更深入的调查。这导致了我在此处发布的注释：Python- Organization for common modules。 python.org 上还有一些问题报告（相同的用户名），以及对其文档的一些修订。我希望这可以帮助其他同样困惑的人。

【讨论】：

我对你的笔记很感兴趣，但是链接失效了。
@A.Donda 那些旧笔记可能已经过时了。它仍然是关于导入功能的方式，以及与 sys.path 等相关的功能，以及它们如何应用于手头的问题——由多个程序共享的库，这些库在非正式的编程场景中并行开发，不打算用于部署远和宽。 IMO 仍然没有一个很好的解决方案来解决这个特定的问题。一些相关问题得到了改进（Python 3.x 提供了创建虚拟环境功能）或更混乱（PEP420 使包模糊 - 请参阅github.com/pypa/setuptools/issues/97）。

【解决方案4】：

Per-user site-packages directory 是另一种选择。你可以试试：

python setup.py install --user

安装到%APPDATA%\Python\Python32 比创建一个全新的virtualenv 轻得多。这就是PyPM 默认所做的。

【讨论】：