Python 在多个存储库中开发
Python Development in multiple repositories
我们正在努力寻找解决该问题的最佳方法。
假设我在 Python 环境中工作，使用 pip 和 setuptools。
我以正常的 git 流程工作，我希望如此。
所以：
- 移动到某些应用程序中的功能分支，进行更改。
- 移动到依赖库中的功能分支 - 开发东西。
- 使用“-e git+ssh”将应用指向依赖库的功能分支。
- 创建拉取请求。
当这一切都完成后，我想将东西合并到 master，但我不能不做另一个最后的改变让应用程序（上面的第 3 步）requirements.txt 现在指向主分支的功能。
"micro services" 或 python 中的多个依赖源代码是否有我们缺少的任何好的工作流程？
Python 从开发到部署的应用程序工作流程
您似乎正在寻找开发 Python 应用程序，使用 git。
以下描述适用于任何类型的基于 Python 的应用程序，
不仅针对 Pyramid 基于网络的。
要求
情况：
- 使用 Pyramid 网络框架开发基于 Python 的解决方案
- 有多个python包，参与最终解决，包可能是依赖的。
- 一些包来自public pypi，其他可能是私人包
- 源代码由git
控制
期望：
- 提议的工作方式应允许：
- 拉取请求
- 适用于依赖包的情况
- 确保部署是可重复的
建议的解决方案
概念：
- 甚至 Pyramid 应用程序也作为版本包发布
- 私人 pypi 使用
devpi-server 包括。 volatile 和 release 索引。
- 要创建包，请使用
pbr
- 使用
tox 进行包单元测试
- 测试，在你发布新的包版本之前
- 测试，部署前
- 保持部署配置独立于应用程序包
Pyramid web 应用程序包
Pyramid 允许以 Python 包的形式创建应用程序。在
事实上，整个初始教程（包含 21 个阶段）正是使用这个
方法。
尽管如此，您可以运行开发模式下的应用程序，您没有
在生产中这样做。 运行 从发布的包中很容易。
Pyramid 使用不错的 .ini 配置文件。将 development.ini 保留在
包存储库，因为它是开发不可或缺的一部分。
另一方面，确保生产 .ini 文件不存在，因为它们
不应与应用程序混合，属于部署内容。
为了使部署更容易，在你的包中添加一个命令，打印到
标准输出典型部署配置。命名脚本，例如myapp_gen_ini.
编写单元测试并将 tox.ini 配置为 运行 它们。
将部署内容与应用程序分开
将应用程序代码与部署配置混合在一起会产生问题
此刻，您将不得不安装到第二个实例（因为您可能
更改至少一行配置）。
在部署存储库中：
- 保留在此处
requirements.txt，其中列出了应用程序包和其他
生产所需的包。请确保您指定确切的包版本
至少你的应用程序包。
- 在此处保留
production.ini 文件。如果您有更多部署，每个部署使用一个分支。
- 放这里
tox.ini
tox.ini内容如下：
[tox]
envlist = py27
# use py34 or others, if your prefer
[testenv]
commands =
deps =
-rrequirements.txt
部署存储库的预期用途是：
- 克隆到服务器
- 运行
tox，这将创建 virtualenv .tox/py27
- 通过
$ source .tox/py27/bin/activate 激活virtualenv
- 如果
production.ini 不存在于 repo 中，运行 命令
$ myapp_gen_ini > production.ini 为生产生成模板
配置
- 根据需要编辑
production.ini。
- 测试，有效。
- 将
production.ini 更改提交到存储库
- 做部署应用程序所需的其他事情（配置网络服务器、supervisord 等）
对于 setup.py 使用 pbr 包
使包创建更简单，并保持与 git 相关的包版本控制
存储库标签，使用 pbr。你最终会得到 setup.py 只有 3 行
long 和所有相关内容将以 ini 的形式在 setup.cfg 中指定
文件。
在你第一次构建之前，你必须在 git 存储库中有一些文件，
否则它会抱怨。当你使用git时，这应该没有问题。
要分配新的软件包版本，请设置 $ git tag -a 0.2.0 并构建它。这会
使用 0.2.0.
版本创建包
作为奖励，它会根据您的提交创建 AUTHORS 和 ChangeLog
消息。将这些文件保存在 .gitignore 中并使用它们创建 AUTHORS.rst
和 ChangeLog.rst 手动（基于自动生成的内容）。
当您将提交推送到另一个 git 存储库时，不要忘记也推送标签。
使用devpi-server作为私有pypi
devpi-server是优秀的私有pypi，它会给你带来以下好处：
- 完全拥有私有 pypi
- 缓存 public pypi 包
- 更快地构建虚拟环境（因为它将从缓存的包中安装）
- 即使没有互联网连接也能使用
pip
- 在各种类型的包索引之间推送：一种用于开发
（发布版本可以在这里更改），一个用于部署（发布版本不会在这里更改）。
- 简单的单元测试 运行 任何有权访问它的人，它甚至会收集
结果并通过网页显示它们。
对于所描述的工作流，它将作为 python 个可以部署的包的存储库。
要使用的命令是：
$ devpi upload上传开发包到服务器$ devpi test <package_name>下载，安装，运行单元测试，
将测试结果发布到 devpi-server 并清理临时安装。$ devpi push ... 将发布的包推送到 devpi-server 甚至 public pypi 上的正确索引。
请注意，始终很容易将 pip 命令配置为使用
来自 devpi 服务器上选定索引的包 $ pip install <package>。
devpi-server 也可以用于持续集成测试。
git 如何融入此工作流程
所描述的工作流程不受特定使用方式的约束 git。
另一方面，git可以在以下情况下发挥作用：
commit: 提交消息将成为自动生成的一部分 ChangeLogtag：定义版本（根据pbr由setup.py识别）。
由于 git 是分布式的，有多个存储库、分支等，
devpi-server 允许类似的分发，因为每个用户都可以拥有自己的
要发布到的工作索引。无论如何，最终会有一个 git 存储库
使用 master 分支。在devpi-server也会有一个约定
生产指数.
总结
描述的过程并不简单，但复杂程度与任务的复杂程度有关。
基于工具：
toxdevpi-serverpbr（Python包）git
建议的解决方案允许：
- 管理 python 个包，包括。发布管理
- 单元测试和持续集成测试
- 任何使用方式
git
- 具有明确定义的范围和交互的部署和开发。
您的问题假设有多个存储库。提议的解决方案允许通过发布到 devpi-server 的管理良好的包版本来分离多个存储库。
我们最终使用了 git 依赖项而不是 devpi。
我觉得用git的时候，不需要另外加包仓库，只要pip能用这个就可以了。
分支代码（由于二级依赖）与合并到 master 的分支代码不同的核心问题尚未解决，相反，我们通过努力消除二级依赖来解决这个问题。
我们正在努力寻找解决该问题的最佳方法。 假设我在 Python 环境中工作，使用 pip 和 setuptools。 我以正常的 git 流程工作，我希望如此。 所以：
- 移动到某些应用程序中的功能分支，进行更改。
- 移动到依赖库中的功能分支 - 开发东西。
- 使用“-e git+ssh”将应用指向依赖库的功能分支。
- 创建拉取请求。
当这一切都完成后，我想将东西合并到 master，但我不能不做另一个最后的改变让应用程序（上面的第 3 步）requirements.txt 现在指向主分支的功能。
"micro services" 或 python 中的多个依赖源代码是否有我们缺少的任何好的工作流程？
Python 从开发到部署的应用程序工作流程
您似乎正在寻找开发 Python 应用程序，使用 git。
以下描述适用于任何类型的基于 Python 的应用程序，
不仅针对 Pyramid 基于网络的。
要求
情况：
- 使用 Pyramid 网络框架开发基于 Python 的解决方案
- 有多个python包，参与最终解决，包可能是依赖的。
- 一些包来自public pypi，其他可能是私人包
- 源代码由git 控制
期望：
- 提议的工作方式应允许：
- 拉取请求
- 适用于依赖包的情况
- 确保部署是可重复的
建议的解决方案
概念：
- 甚至 Pyramid 应用程序也作为版本包发布
- 私人 pypi 使用
devpi-server包括。 volatile 和 release 索引。 - 要创建包，请使用
pbr - 使用
tox进行包单元测试 - 测试，在你发布新的包版本之前
- 测试，部署前
- 保持部署配置独立于应用程序包
Pyramid web 应用程序包
Pyramid 允许以 Python 包的形式创建应用程序。在 事实上，整个初始教程（包含 21 个阶段）正是使用这个 方法。
尽管如此，您可以运行开发模式下的应用程序，您没有 在生产中这样做。 运行 从发布的包中很容易。
Pyramid 使用不错的 .ini 配置文件。将 development.ini 保留在
包存储库，因为它是开发不可或缺的一部分。
另一方面，确保生产 .ini 文件不存在，因为它们
不应与应用程序混合，属于部署内容。
为了使部署更容易，在你的包中添加一个命令，打印到
标准输出典型部署配置。命名脚本，例如myapp_gen_ini.
编写单元测试并将 tox.ini 配置为 运行 它们。
将部署内容与应用程序分开
将应用程序代码与部署配置混合在一起会产生问题 此刻，您将不得不安装到第二个实例（因为您可能 更改至少一行配置）。
在部署存储库中：
- 保留在此处
requirements.txt，其中列出了应用程序包和其他 生产所需的包。请确保您指定确切的包版本 至少你的应用程序包。 - 在此处保留
production.ini文件。如果您有更多部署，每个部署使用一个分支。 - 放这里
tox.ini
tox.ini内容如下：
[tox]
envlist = py27
# use py34 or others, if your prefer
[testenv]
commands =
deps =
-rrequirements.txt
部署存储库的预期用途是：
- 克隆到服务器
- 运行
tox，这将创建 virtualenv.tox/py27 - 通过
$ source .tox/py27/bin/activate激活virtualenv
- 如果
production.ini不存在于 repo 中，运行 命令$ myapp_gen_ini > production.ini为生产生成模板 配置 - 根据需要编辑
production.ini。 - 测试，有效。
- 将
production.ini更改提交到存储库 - 做部署应用程序所需的其他事情（配置网络服务器、supervisord 等）
对于 setup.py 使用 pbr 包
使包创建更简单，并保持与 git 相关的包版本控制
存储库标签，使用 pbr。你最终会得到 setup.py 只有 3 行
long 和所有相关内容将以 ini 的形式在 setup.cfg 中指定
文件。
在你第一次构建之前，你必须在 git 存储库中有一些文件， 否则它会抱怨。当你使用git时，这应该没有问题。
要分配新的软件包版本，请设置 $ git tag -a 0.2.0 并构建它。这会
使用 0.2.0.
作为奖励，它会根据您的提交创建 AUTHORS 和 ChangeLog
消息。将这些文件保存在 .gitignore 中并使用它们创建 AUTHORS.rst
和 ChangeLog.rst 手动（基于自动生成的内容）。
当您将提交推送到另一个 git 存储库时，不要忘记也推送标签。
使用devpi-server作为私有pypi
devpi-server是优秀的私有pypi，它会给你带来以下好处：
- 完全拥有私有 pypi
- 缓存 public pypi 包
- 更快地构建虚拟环境（因为它将从缓存的包中安装）
- 即使没有互联网连接也能使用
pip - 在各种类型的包索引之间推送：一种用于开发 （发布版本可以在这里更改），一个用于部署（发布版本不会在这里更改）。
- 简单的单元测试 运行 任何有权访问它的人，它甚至会收集 结果并通过网页显示它们。
对于所描述的工作流，它将作为 python 个可以部署的包的存储库。
要使用的命令是：
$ devpi upload上传开发包到服务器$ devpi test <package_name>下载，安装，运行单元测试， 将测试结果发布到 devpi-server 并清理临时安装。$ devpi push ...将发布的包推送到devpi-server甚至 public pypi 上的正确索引。
请注意，始终很容易将 pip 命令配置为使用
来自 devpi 服务器上选定索引的包 $ pip install <package>。
devpi-server 也可以用于持续集成测试。
git 如何融入此工作流程
所描述的工作流程不受特定使用方式的约束 git。
另一方面，git可以在以下情况下发挥作用：
commit: 提交消息将成为自动生成的一部分ChangeLogtag：定义版本（根据pbr由setup.py识别）。
由于 git 是分布式的，有多个存储库、分支等，
devpi-server 允许类似的分发，因为每个用户都可以拥有自己的
要发布到的工作索引。无论如何，最终会有一个 git 存储库
使用 master 分支。在devpi-server也会有一个约定
生产指数.
总结
描述的过程并不简单，但复杂程度与任务的复杂程度有关。
基于工具：
toxdevpi-serverpbr（Python包）git
建议的解决方案允许：
- 管理 python 个包，包括。发布管理
- 单元测试和持续集成测试
- 任何使用方式
git - 具有明确定义的范围和交互的部署和开发。
您的问题假设有多个存储库。提议的解决方案允许通过发布到 devpi-server 的管理良好的包版本来分离多个存储库。
我们最终使用了 git 依赖项而不是 devpi。 我觉得用git的时候，不需要另外加包仓库，只要pip能用这个就可以了。
分支代码（由于二级依赖）与合并到 master 的分支代码不同的核心问题尚未解决，相反，我们通过努力消除二级依赖来解决这个问题。