【问题标题】:Building a python wheel that includes svn:externals files on Jenkins在 Jenkins 上构建一个包含 svn:externals 文件的 python 轮子
【发布时间】:2014-11-04 11:31:50
【问题描述】:

我正在 Python 2.7.6 32bit Windows 32 上构建一个包

软件包某些组件的唯一确定来源是 svn 'share'。这家公司的常见做法是使用 svn:externals 将其包含到您的项目中。

构建这个包的正常方式是:

python setup.py bdist_wheel

在我的工作站上一切正常(我用 TortoiseSVN 检查了代码),但是当我在 Jenkins 上运行相同的进程时,bdist_wheel 进程不包含任何通过 svn:externals 获取的 .py 文件。

阅读完文档后,这似乎是因为一个功能可以根据 SVN 跟踪的文件来识别哪些脚本是包的一部分。看来,由于 Jenkins 检查文件的方式,bdist_wheel 看到我正在使用 SVN,并假设它知道如何确定跟踪哪些文件,但得到的答案是错误的。

我需要一种方法来阻止 bdist_wheel 命令尝试猜测我关心哪些文件(我实际上希望项目中的每个 .py 文件都包含在内,无论它是如何引入的)

我尝试使用 MANIFEST.in 文件指定我需要的文件,但没有成功。

recursive-include externals *.py

在本例中,'externals' 是我的源代码树中的顶级目录,其中包含一个 init.py 文件和一堆 svn:external'd 目录。在构建的 whl 文件中只能看到 init 文件。

不幸的是,这使得 .py 文件的行为就好像它们是数据一样,在日志中我可以看到:

copying build\lib\externals\security\credentials.py -> build\bdist.win32\wheel\foopackage-0.0.4.data\..\externals\security

这显然不是真正的解决方案!

Pip、Virtualenv 和所有相关工具都是最新的稳定版本。

【问题讨论】:

    标签: python svn setuptools distribute python-wheel


    【解决方案1】:

    事实证明,这个问题是由 Jenkins 使用非常古老的 SVN 标准 (1.4) 为其自己的存储库引起的。切换到 1.7 可以更正此行为。

    【讨论】:

      猜你喜欢
      • 2018-05-26
      • 1970-01-01
      • 1970-01-01
      • 2020-05-02
      • 2016-06-08
      • 2016-07-15
      • 2019-06-08
      • 1970-01-01
      • 2018-06-13
      相关资源
      最近更新 更多