有关管理大型、多方面的企业 Python 代码库的信息？

Question

我用谷歌搜索和搜索，但几乎没有发现任何关于用 Python 管理大型企业代码库的讨论或最佳实践。在这里，我只是在征求任何和所有指向此类信息的指针。以下是一些背景知识和一些我希望回答的问题。

我们是长期的 Java 开发人员，他们主要使用成熟的 Java 最佳实践以及 Maven、Ant 和 Sonotype Nexus 存储库解决了与下面提到的问题类似的问题。

我在这里只谈论内部软件。我们不打算分发任何基于 Python 的东西。我们有多个使用 Python 的开发组，每个开发组都使用纯 Python 开发可共享的实用程序代码库、最终的 Web 应用程序和独立工具。每个组都有自己的 Github 源代码库。

我们如何在组内和跨组管理我们的可共享代码？我们是否创建鸡蛋（或类似的东西）并将它们分发并安装到 Python 系统中？如果是这样，我们会将它们存储在我们的 Nexus 存储库中，就像我们的 Java jar 一样，或者如果内部包分发，是否有更特定于 Python 的方法？或者，我们只是共享原始代码，查看来自多个 Github 存储库的源代码？

如果我们共享原始代码，当我们将来自多个存储库的代码汇集在一起​​时，我们如何管理正确的 Python 搜索路径？

当我们希望我们的包都存在于 com.ourcompany 基本命名空间中时，我们如何管理包命名空间？当您将具有重叠命名空间的源代码树放在一起时，python 似乎不太高兴。

我们如何管理第三方软件包版本控制？我从未见过 easy_install 或 pip 传递版本号。我们如何锁定第三方软件包版本？

是否存在有助于 Python 代码审查、CI、回归测试等的工具？

我们是 Python 代码的相对新手，因此其中一些问题可能有相当明显的答案。不过，令我惊讶的是，我找不到有关管理更大 Python 代码库的更多信息。

我们会遇到哪些我没有想过要问的问题，或者还不知道要问的问题？

任何有价值的指针将不胜感激。

Answer 1

好吧，我什至不会尝试回答所有那些（优秀的）问题，但这里有一些自以为是的建议，希望能有所帮助（作为一个在两个世界中工作的人，虽然更多的是 Java )。

包装

如果是这样，我们会将它们存储在我们的 Nexus 存储库中，就像我们的 Java jars 一样，或者是 如果内部包分发，还有更多特定于 Python 的方法吗？ 或者，我们只是共享原始代码，检查来自多个 Github 仓库？

恕我直言，Python 中的打包在历史上有点混乱，尽管感觉它正在改进。 Distutils 是这里的主要/原生工具 - 我用的不多，有些地方感觉有点吓人。一般来说，还要检查recommended tools。

Pip 几乎赢得了心灵分享之战，尤其是在安装 3rd 方库时。我自己还没有解决本地图书馆的问题，（也许其他人正在阅读），但如果我是，我可能会选择带有本地/网络磁盘存储库的 Pip，例如installing from wheels.

另一种选择（它本身可能会引起各种麻烦）是在您的操作系统的本机打包程序中打包，无论是 Debian 风格的 apt 还是 creating RPMs 等。当然，Windows 没有那么多。

版本控制等

我们如何管理第三方软件包版本控制？我从未见过 easy_install 或 pip 传递了一个版本号。

点

Pip definitely supports version specifiers。结果是Easy Install does too。我想很多人/较小的项目会选择最新最好的，当然这在企业中并不总是“合适”的......

虚拟环境

没有任何关于版本控制和 Python 的讨论会错过 Python2/3 参考，但我相信您已经知道这一切。

然后更重要的是提及virtualenv。它真正让您从测试多个版本时可能陷入的混乱中解脱出来，尤其要记住您的 (*NIX) 操作系统通常严重依赖 Python 本身。这是一个很大的主题，所以请查看文档。

开发者工具

是否存在有助于 Python 代码审查、CI、回归测试、 等等？

代码审查

非常喜欢。大多数代码审查工具都是多语言的（这实际上只是一个格式问题），所以只需选择您最喜欢的企业友好型工具，无论是 Crucible、Github 的工具（Barkeep？）、Gerrit 或其他任何工具。

CI

对于 CI，您再次拥有几乎一样多的选择。运行 python 应用程序通常比 Java 应用程序更少涉及，因此大多数 CI 系统虽然通常以 Java 为重点，但都支持 Python。 （FWIW，我们将drone.io 用于Quod Libet）。 Jenkins 这样做应该没有问题，而且似乎人们有 done so with TeamCity。

但是，“原始”或“最 Pythonic”可能是 Buildbot，但我个人没有使用过。看起来比我记得的要新得多，而且我认为它在 Python 社区中得到了相当多的支持......

测试

对于测试，虽然不像 JUnit / TestNG 那样相当 成熟，请查看事实上的 / JUnit-like 单元测试unittest，还有（更好的？）替代方案，如nose.py .

对于更高级别 (BDD) 的测试，请尝试 Lettuce 之类的东西 - 顾名思义，它深受 Cucumber 的启发，或者可能是 Behave。我没有尝试过，但普遍认为它们不如 Cucumber / JBehave / Concordion / Rspec 等成熟。