在具有 git 个子模块或 svn:externals 的应用程序之间共享 python 个模块

Question

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

一种可能性是使用 virtualenv 从本地 pypi 服务器安装模块。所以在每次初始结帐时，我们需要创建一个 virtualenv，激活它并安装来自 requirements.txt.

的依赖模块

缺点：

结帐和运行
您可能会错过 virtualenv 的创建和使用站点包中安装的模块的工作
需要一个本地 pypi 服务器（好的，否则你可以使用指向你的 vcs 的 urls）

所以我们想出了另一个解决方案，我征求你的意见：在应用程序的路径中，我们使用 svn:externals（又名 git 子模块）到 "link" 到指定的模块（从它的发布路径和指定的修订号以保持它只读），所以该模块将本地放置在应用程序的路径中。 "import mylib" 将像安装在 python 站点包或 virtualenv 中一样工作。这可以扩展到甚至将 wx、numpy 和其他常用库的版本放入我们的存储库并 link 在本地。

优点是：

初次结帐后，您就可以运行（对我来说非常重要）
版本依赖性已修复（如requirements.txt）

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

PS：我已经在 pypa-dev 邮件列表上 post 编辑了这个，但它似乎不是此类问题的错误位置。请原谅这个十字post.

Answer 1

In the path of the application we use svn:externals (aka git submodules) to "link" to the specified module (from it's release path and with specified revision number to keep it read only), so the module will be placed locally in the path of the application.

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

After the initial checkout you're ready to run

...这不完全正确。如果您的依赖项之一是用 C 编写的 Python 库，则需要先编译它。

We tried it with git's submodule functionality but it's not possible to get a subpath of a repository (like /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

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

Are there projects out there on github/sourceforge using this scheme?

子模块信息仅存储在名为 .gitmodules 的文件中，并且快速 Google for "site:github.com .gitmodules" returns 相当多的结果。

Why is everybody using virtualenv instead of this (seemingly) simpler scheme?

对于在 PyPI 上发布并使用 pip 安装的包，从依赖管理的角度来看，它可以说更容易。

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

myproject
|- libfoo
|- libbar

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

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

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

在您的具体情况下，关于您的解决方案是否正确的决定将取决于问题的答案：-

您需要使用的所有外部模块实际上都可以从 svn 个存储库中获得吗？
这些存储库是否正确使用 svn:externals 来包含它们所需的任何依赖项的兼容版本，或者如果没有，您是否准备好自己承担管理这些依赖项的责任？

如果两个问题的答案都是 "yes"，那么您的解决方案可能适合您的情况。

在具有 git 个子模块或 svn:externals 的应用程序之间共享 python 个模块

Sharing python modules between applications with git sub modules or svn:externals

python

git

svn

virtualenv

packaging