使用git子模块或svn：externals在应用程序之间共享python模块

Question

在我们公司中，我们使用的是Subversion。我们使用不同版本的不同python模块（自有和第三方）。我们开发的各种应用程序对共享模块的版本具有各种依赖性。

一种可能性是使用virtualenv从本地pypi服务器安装模块。因此，在每次初始结帐时，我们都需要创建一个virtualenv，将其激活并从requirements.txt安装相关模块。

缺点：

• 相对简单的任务（如签出和运行）的相对复杂的操作
• 您可能会错过virtualenv的创建以及使用站点包中安装的模块的念头
• 需要本地pypi服务器（好的，否则您可以使用指向您的vcs的网址）

因此，我们提出了另一个解决方案，请征询您的意见：在应用程序的路径中，我们使用svn：externals（又名git子模块）将其“链接”到指定的模块（从其发布路径并保留指定的修订号） （只读），因此该模块将被本地放置在应用程序的路径中。“ import mylib”将在python站点软件包或virtualenv中安装时起作用。甚至可以将wx，numpy和其他常用库的发行版放到我们的存储库中并在本地链接它们。

优点是：

• 初次结帐后，您就可以开始跑步了（对我而言非常重要）
• 版本依赖关系是固定的（例如requirements.txt）

实际的问题是：是否使用此方案在github / sorceforge上有项目？为什么每个人都使用virtualenv代替这个（看似）更简单的方案？我从未见过这样的解决方案，所以也许我们错过了一点？

PS：我已经在pypa-dev邮件列表上发布了此内容，但对于此类问题似乎是错误的地方。请原谅这个交叉口。

Answer 1

在应用程序的路径中，我们使用svn：externals（又名git子模块）“链接”到指定的模块（从其发布路径开始，并使用指定的修订版号保持只读），因此该模块将本地放置在应用程序的路径。

这是一种用于管理程序包依赖关系的更传统的方法，并且是仅在内部使用的两个选项中的一个更简单。关于...

初始结帐后，您就可以运行了

...并非完全正确。如果您的依赖项之一是用C编写的Python库，则需要先对其进行编译。

我们使用git的子模块功能进行了尝试，但无法获取存储库的子路径（如/source/lib）

如果您在以外的某个位置检出整个存储库，则可以轻松解决此问题PYTHONPATH，然后只需符号链接到内部所需的文件或目录即可PYTHONPATH，尽管它确实要求您使用支持符号链接的文件系统。

例如，布局如...

myproject
|- bin
|  |- myprogram.py
|
|- lib
|  |- mymodule.py
|  |- mypackage
|  |  |- __init__.py
|  |
|  |- foopackage -> ../submodules/libfoo/lib/foopackage
|  |- barmodule
|     |- __init__.py -> ../../submodules/libbar/lib/barmodule.py
|
|- submodules
   |- libfoo
   |  |- bin
   |  |- lib
   |     |- foopackage
   |        |- __init__.py
   |
   |- libbar
       |- bin
       |- lib
          | barmodule.py

...您只需要my_project/lib在中PYTHONPATH，所有内容都应正确导入。

使用此方案在github / sourceforge上是否有项目？

子模块信息只是存储在一个名为的文件中.gitmodules，而针对“ site：github.com .gitmodules”的快速Google会返回很多结果。

为什么每个人都使用virtualenv代替这个（看似）更简单的方案？

对于在PyPI上发布并与一起安装的软件包pip从依赖关系管理的角度来看，这无疑是容易的。

如果您的软件具有相对简单的依赖关系图，例如...

myproject
|- libfoo
|- libbar

...没什么大不了的，但是当它变得更像...

myproject
|- libfoo
|  |- libsubfoo
|     |- libsubsubfoo
|        |- libsubsubsubfoo
|           |- libsubsubsubsubfoo
|- libbar
   |- libsubbar1
   |- libsubbar2
   |- libsubbar3
   |- libsubbar4

...如果您libbar出于任何原因需要升级，您可能不想承担确定所有这些子软件包的哪个版本兼容的责任。您可以将该责任委托给libbar软件包的维护者。

在您的特定情况下，关于您的解决方案是否正确的决定取决于以下问题的答案：

1. 您需要使用的所有外部模块是否可以从svn存储库中实际获得？
2. 这些存储库svn:externals是否正确使用了包含所需的任何依赖项的兼容版本，或者如果不需要，您是否准备好亲自管理这些依赖项？

如果两个问题的答案均​​为“是”，那么您的解决方案可能适合您的情况。