【问题标题】:Organizing Python projects with shared packages使用共享包组织 Python 项目
【发布时间】:2010-12-14 01:43:52
【问题描述】:

组织和开发由许多共享一个(或多个)较大 Python 库的小脚本组成的项目的最佳方法是什么?

我们的存储库中有一堆程序,它们都使用存储在同一个存储库中的相同库。所以换句话说,像

这样的布局
trunk
    libs
        python
        utilities
    projects
        projA
        projB

当我们的程序正式运行完成后,我们想记录下使用了哪个版本的代码。对于我们的 C++ 可执行文件,事情很简单,因为只要工作副本在编译时是干净的,一切都很好。 (而且由于我们以编程方式获取版本号,因此它必须是工作副本,而不是导出。)对于 Python 脚本,事情就更复杂了。

问题在于,通常会运行一个项目(例如 projA),而 projB 需要更新。这可能会导致工作副本修订在运行时与 projA 混在一起。 (代码需要数小时才能运行,并且可以用作需要数天才能运行的流程的输入,因此具有强大的可追溯性目标。)

我目前的解决方法是,如有必要,将主干的另一个副本检查到不同的位置,然后从那里跑掉。但是我需要记住将我的 PYTHONPATH 更改为指向 lib/python 的第二个版本,而不是第一个树中的那个。

不可能有一个完美的答案。但一定有更好的办法。

我们是否应该使用 subversion 关键字来存储修订号,这将允许数据用户导出文件?我们应该使用 virtualenv 吗?我们是否应该更倾向于打包和安装机制? Setuptools 是标准,但我读过关于它的混合内容,它似乎是为非开发人员最终用户设计的(我们没有)。

【问题讨论】:

  • 您是说在实时代码使用它们的同时更改生产库吗?
  • 我是说这有可能发生。在我正式运行这些程序时,确实发生了类似的事情。我没有更改当前使用的工作副本中的任何代码,但 svn 不知道,所以它说它是一个混合存储库。我的跑步抛出了一个异常,这是应该的。由于该项目中的大多数人都不关心使用干净的副本,因此我希望尽可能减少这种可能性。

标签: python svn version-control code-organization


【解决方案1】:

更好的解决方案是不要将所有项目及其共享依赖项存储在同一个存储库中。

每个项目使用一个存储库,externals 用于共享库。

利用共享库存储库中的标签,因此消费者项目可以在其外部使用他们需要的版本。

编辑:(只是从我的评论中复制)如果您需要为同一服务器上的不同应用程序提供隔离的运行时环境,请使用 virtualenv。然后每个环境都可以包含它需要的唯一版本的库。

【讨论】:

  • 我同意,并且已经想使用它们一年多了,但似乎没有其他人推动它们。我们有一些程序员对“svn cp”有问题; svn externals 对他们来说太复杂了。此外,没有构建系统的使用都不是很熟练,并且会知道如何设置它。但最重要的是,这并不能解决轻松控制 Python 在哪里查看 runtime 的问题。
  • AFoglia,也许你可以使用 virtualenv 为每个项目创建一个单独的运行时环境。
  • 我一直在玩 virtualenv,我认为它会做我想做的事。首先,我需要弄清楚如何使用 setuptools 轻松安装软件包,但这是另一个问题。
  • @AFoglia,你现在可能已经知道'pip'了......假设你有一个用于这些'共享'包的setup.py,创建一个virtualenv,一个requirements.txt,和类似。 pip install -e /some/path 通常做正确的事情。
【解决方案2】:

如果我正确理解了您的问题,那么您肯定想要 virtualenv。添加一些 virtualenvwrapper 的优点,让它变得更好。

【讨论】:

    猜你喜欢
    • 2015-08-04
    • 1970-01-01
    • 2022-01-17
    • 1970-01-01
    • 2020-02-05
    • 1970-01-01
    • 2012-10-21
    • 1970-01-01
    • 2017-07-03
    相关资源
    最近更新 更多