openstack python依赖管理工具
openstack-requirements的Python项目详细描述
====
团队和存储库标记
==
==
图片：：https://governance.openstack.org/tc/badges/requirements.svg
：目标：https://governance.openstack.org/tc/reference/tags/index.html
…从这一点出发，在
=======================================================================================================================================================================
==
在哈瓦那发布周期中，我们一直遇到一致性问题，试图将所有openstack组件安装到一个环境中。问题是，在
项目之间同步"requirements.txt"是一个最终一致的问题。有些项目会快速更新，而其他项目则不会。我们永远不会有相同的版本指定为包之间的需求。
如果不这样做，您可以在
需求更新时轻松地断开所有openstack。
一个很糟糕的例子是，python keystoneclient
在哈瓦那运行devstack gate的过程中通常会安装/卸载6次。如果最后一个版本的python
keystoneclient碰巧与openstack的某个部分不兼容，则会发生很难诊断的中断。
那些图书馆。图书馆是否积极维护？
许可证库是否兼容？库是否复制了我们在需求中已有的现有
库的功能？库python
3是否兼容？是我们的目标linux
发行版（ubuntu/fedora）中已经存在的库。许多这些问题的答案都是否定的。
全球需求为我们提供了一个评估
这些东西的地方，这样我们就可以对openstack做出一个关于
库的适用性的全球决策。
中断是由于与openstack不兼容的软件的上游版本（无论是小型版本还是大型版本）导致的。因此，全局需求也可以作为控制点来确定在ci期间将要使用的依赖关系的精确版本。
我们维护了openstack项目中允许的所有需求（``global requirements.txt`）
的中心列表。这是针对
``requirements.txt``、``test requirements.txt``、
``doc/requirements.txt```和在
``setup.cfg``中定义的附加文件强制执行的。这是手工维护的，更改通过ci进行。
建议对此存储库进行更改。这样做的一个结果是，OpenStack库的新版本并没有立即使用：它们必须通过这个自动化的过程，然后我们才能从中受益（或者受到它们的伤害）。
format
----
`global requirements.txt``支持PIP的一个子集需求文件
内容。发行版只能按名称引用，不能按url引用。选项
（例如-e或-f）不能使用。版本说明符、环境标记
和注释都是允许的。如果使用不同的标记需要不同的说明符，那么一个发行版可能会被列出不止一次（对于
实例，如果依赖项已经放弃了Python2.7支持，
``upper constraints.txt``Is机器生成，只不过是
一个精确的版本列表。
`` edit constraints``可用于取消固定单个约束，
这是为了从git安装库而完成的。
我们正在进行必要的更改，以便在
tox作业中使用"upper constraints.txt"，但尚未完成。
接受的需求契约（如``projects.txt``中列出的
）预期将运行一个需求兼容性
作业。此作业确保项目不能将任何依赖项更改为与"global requirements.txt"不兼容的
版本。它还确保
这些项目不能添加
`` global requirements.txt``中没有的需求。此"检查需求"作业应在提议更改
"openstack/requirements"中的"projects.txt"之前合并到infra中。
并接受
"global requirements.txt"，然后，系统还会自动将新需求定义的评审请求推送到包含它的项目中。
向所有openstack项目提交补丁，这些项目将python keystoneclient列为符合新版本定义的需求或测试需求。
因为它们可以
快速批准需求同步，而不必手动担心
它们是否与全局定义最新。
工具
=
所有工具都需要安装OpenStack_需求（例如，在Python中
Virtualenv）。他们都有帮助，这是权威文档。
更新需求
----
这将从位于`.``中的全局需求
文件更新项目中的需求。或者，传递`--source``以使用不同的
全局需求文件：：
update requirements--source/opt/stack/requirements/opt/stack/nova
所有需求文件中的条目都将更新其版本以匹配
全局需求中列出的条目。过多的条目将在硬模式（默认）下导致
错误，或在软模式下被忽略。
生成约束-p/usr/b in/python2.7-p/usr/bin/python3\-b blacklist.txt-r global-requirements.txt>；new constraints.txt
devstack使用它来启用库的git安装，这些库通常受到限制：：
edit constraints oslo.db"-e file://opt/stack/oslo.db\egg=oslo.db"
它们。
对"global requirements.txt"的所有更改都可能由于添加或删除可传递的依赖关系而显著更改"upper constraints.txt"的内容。因此，您应该始终针对当前合并的约束生成diff，否则，如果更改与当前测试的约束不兼容，则更改可能会失败。
编译各种python包：：
sudo apt get install$（bindep-b）
2）创建一个引用文件（在不应用补丁的情况下执行此操作）：：
generate constraints-p/usr/bin/python2.7-p/usr/bin/python3\
-b blacklist.txt-r global-requirements.txt>；基线
3）应用修补程序并生成新的引用文件：：
generate constraints-p/usr/bin/python2.7-p/usr/bin/python3 \
-b blacklist.txt-r global-requirements.txt>；已更新
4）差异它们：：
diff-p基线已更新
5）应用"upper constraints.txt"的修补程序。这可能需要一些
摆弄。``当更改不涉及一个包的多行时，编辑约束``可以为您**。
建议者可以通过将这些问题的答案包含在提交信息中，从而使评审变得更容易，因为
他们的更改。
一般评审标准
重视上游需求中断的早期反馈，因此除了处理异常不稳定的库时，应避免版本上限。
如果库异常不稳定，我们还应该考虑是否要随着时间的推移用一个稳定的库来替换它，或者帮助上游社区稳定它。如果不知道工作最小值是什么，请查看成功运行devstack/tempest时pip freeze的输出并使用该版本。至少
现在可以工作了。
-提交消息应该引用正在使用的项目
理想情况下，应该已经提出更改，以便可以看到其用途。
-黑名单用于处理不受限制的依赖项。
例如，每个项目具有不同版本级别的linter，
这使得项目在每个版本上都失败（因为它们添加了规则）
除非我们同时协调将所有的openstack更新到新版本上，否则这些不能受到全局限制-但是考虑到志愿者和松散耦合的大帐篷不可行的只在不受约束的地方使用的依赖项不应被列入黑名单-它们在将来可能会受到约束，并且今天约束它们不会造成危害。黑名单中的条目应该有一个注释，解释黑名单的原因。
-只有更新"projects.txt"的评论应该在其他评论旁边或之前获得工作流批准，以便OpenStack提议bot的传播在对其他项目来说是可能的。对于项目
移除或添加，当前ptl的+1（或如果ptl提议
更改，则为核心）应足够。
对于新的需求
----
-库是否得到积极维护？
如果我们或我们的用户发现了一个bug，我们*真的*想知道这个库是我们可以获得支持的，而且我们不需要接管和分叉库。
指向最近上游活动的指针和一致的发布模型是值得赞赏的。
-库代码好吗？
在告诉每个人从互联网上下载任意第三方代码之前，提交者应该已经深入到代码中，以了解该代码是否看起来像足够可靠。这包括确保上游代码有一些合理的测试。
-库python 3兼容吗？
openstack最终需要支持python 3。此时，添加不兼容python 3的库只能在
*extreme*need下完成。这应该被认为是一个非常大的例外。
-库许可证是否兼容？
应按照"许可要求"中的说明对库进行许可，
，并应在与添加的依赖项相同的行上的注释中对许可进行说明。如果您对许可兼容性有疑问，例如在添加gpl测试依赖项时，可以向robert collins（lifeless）寻求建议，monty taylor（mordred）或jim blair（jeblair）。
-这个库是否已经打包在我们的目标发行版中（ubuntu
latest/fedora latest）？
通过在openstack``global requirements.txt``中添加一些内容，我们基本上要求linux发行版在openstack的下一个版本中打包这些内容。如果他们已经有了，太好了。如果没有，我们应该小心添加它。：ref:`finding distro status`
-此库的功能是否已被"global requirements.txt"中的其他库所覆盖？
每个人都有自己喜欢使用的pet库，但是我们不需要openstack中的三个不同的请求模拟库。
然后，我们还需要
转换计划，以便在合理的
时间内删除旧库。
-openstack项目或相关开发或
基础设施设置需要库吗？（当然，答案应该是肯定的）
哪个？
请提供详细信息，例如gerrit更改请求或启动板
指定添加此库需要的bug/blueprint。
-如果库版本由openstack版本进程管理，则它使用"带中间层的循环"版本类型？
这是为了确保使用需求的更新版本
可用于与其他
项目的集成/可安装性测试。
-是否需要更新其他内容？
添加新库时，需要将发行版的初始版本添加到"upper constraints.txt"中。之后，openstack proposal bot将
建议更新。_许可要求：https://governance.openstack.org/tc/reference/licensing.html
用于升级要求版本的
--------------------------
-为什么不可能使用当前版本定义？
每个人都喜欢其他人使用其最新版本的代码。然而，部署人员确实不喜欢不断更新
内容。除非实际上**不可能**使用"global requirements.txt"中指定的最低版本，它不应该被更改。
让部署人员和发行版来决定。
-更新由OpenStack社区开发的库的最低版本的更改可以由一个审阅者批准，只要
约束条件正确且测试通过。
…_ finding-distro-status:
finding-distro-status
---------
来自OpenStack发行版支持策略：
OpenStack将其开发工作瞄准最新的Ubuntu/Fedora，
，但不会引入任何更改，使其无法在最新的ubuntu LTS或最新的RHEL。
s:
-ubuntu-http://packages.ubuntu.com/
-fedora-https://apps.fedora project.org/packages/
-gentoo-https://packages.gentoo.org/
-suse-https://build.opensuse.org/project/show/devel:languages:python
for``upper constraints.txt``如果更改是由openstack ci bot提出的，则如果更改已通过ci，则只需要一个审阅者，而且他们应该+2+a而不必考虑事物。
如果更改不是由openstack ci bot提出的，只有
更改了新库版本的"upper constraints.txt"条目，
如果更改通过了测试，则应予以批准。请参阅openstack/releases中的
readme.rst，以获取有关release
过程的更多详细信息。
然后应该拒绝它：ci
bot本身将生成适当的更改。如果需要更快地运行bot，请在openstack infra中询问。
在这种情况下，忽略对"upper constraints.txt"的更改，并查看更改的
``global requirements.txt``组件。
发布项目。releases
项目确保了有效的稳定版本（很少甚至没有api级别的更改，只有bug
等等）。一旦发布，新版本就需要在
需求中更新。以下限制有助于确保稳定的
分支不会中断。
-在稳定的分支中，我们通常只更新openstack社区中管理的
项目的约束。当
存在浇口问题时，其他项目也有例外。这些更新必须由手工提出。
-需求团队还验证新版本的需求更改
与稳定分支（GR和UC）中的需求一致。
稳定的分支，主要是屏蔽已知的
错误版本，或者极端地增加一个包允许的最大版本。
我们也要删除这些帽。只有在"第一阶段"期间才可以提高有效最低值，而且这只是由于安全问题。
_第一阶段：https://docs.openstack.org/project team guide/stable branches.html；支持阶段
允许这样做的一个例子是：依赖项的依赖项有一个影响openstack的问题。
它没有列在global-requirements.txt中，但它是必需的。为了
阻止受影响的版本并仍然能够保持需求同步，我们在global-requirements.txt中列出库并更新所有需要它的项目。
resources
==
-文档：https://docs.openstack.org/requirements/latest/
-wiki:https://wiki.openstack.org/wiki/requirements
-错误：https://launchpad.net/openstack要求
团队和存储库标记
==
==
图片：：https://governance.openstack.org/tc/badges/requirements.svg
：目标：https://governance.openstack.org/tc/reference/tags/index.html
…从这一点出发，在
=======================================================================================================================================================================
==
在哈瓦那发布周期中，我们一直遇到一致性问题，试图将所有openstack组件安装到一个环境中。问题是，在
项目之间同步"requirements.txt"是一个最终一致的问题。有些项目会快速更新，而其他项目则不会。我们永远不会有相同的版本指定为包之间的需求。
如果不这样做，您可以在
需求更新时轻松地断开所有openstack。
一个很糟糕的例子是，python keystoneclient
在哈瓦那运行devstack gate的过程中通常会安装/卸载6次。如果最后一个版本的python
keystoneclient碰巧与openstack的某个部分不兼容，则会发生很难诊断的中断。
那些图书馆。图书馆是否积极维护？
许可证库是否兼容？库是否复制了我们在需求中已有的现有
库的功能？库python
3是否兼容？是我们的目标linux
发行版（ubuntu/fedora）中已经存在的库。许多这些问题的答案都是否定的。
全球需求为我们提供了一个评估
这些东西的地方，这样我们就可以对openstack做出一个关于
库的适用性的全球决策。
中断是由于与openstack不兼容的软件的上游版本（无论是小型版本还是大型版本）导致的。因此，全局需求也可以作为控制点来确定在ci期间将要使用的依赖关系的精确版本。
我们维护了openstack项目中允许的所有需求（``global requirements.txt`）
的中心列表。这是针对
``requirements.txt``、``test requirements.txt``、
``doc/requirements.txt```和在
``setup.cfg``中定义的附加文件强制执行的。这是手工维护的，更改通过ci进行。
建议对此存储库进行更改。这样做的一个结果是，OpenStack库的新版本并没有立即使用：它们必须通过这个自动化的过程，然后我们才能从中受益（或者受到它们的伤害）。
format
----
`global requirements.txt``支持PIP的一个子集需求文件
内容。发行版只能按名称引用，不能按url引用。选项
（例如-e或-f）不能使用。版本说明符、环境标记
和注释都是允许的。如果使用不同的标记需要不同的说明符，那么一个发行版可能会被列出不止一次（对于
实例，如果依赖项已经放弃了Python2.7支持，
``upper constraints.txt``Is机器生成，只不过是
一个精确的版本列表。
`` edit constraints``可用于取消固定单个约束，
这是为了从git安装库而完成的。
我们正在进行必要的更改，以便在
tox作业中使用"upper constraints.txt"，但尚未完成。
接受的需求契约（如``projects.txt``中列出的
）预期将运行一个需求兼容性
作业。此作业确保项目不能将任何依赖项更改为与"global requirements.txt"不兼容的
版本。它还确保
这些项目不能添加
`` global requirements.txt``中没有的需求。此"检查需求"作业应在提议更改
"openstack/requirements"中的"projects.txt"之前合并到infra中。
并接受
"global requirements.txt"，然后，系统还会自动将新需求定义的评审请求推送到包含它的项目中。
向所有openstack项目提交补丁，这些项目将python keystoneclient列为符合新版本定义的需求或测试需求。
因为它们可以
快速批准需求同步，而不必手动担心
它们是否与全局定义最新。
工具
=
所有工具都需要安装OpenStack_需求（例如，在Python中
Virtualenv）。他们都有帮助，这是权威文档。
更新需求
----
这将从位于`.``中的全局需求
文件更新项目中的需求。或者，传递`--source``以使用不同的
全局需求文件：：
update requirements--source/opt/stack/requirements/opt/stack/nova
所有需求文件中的条目都将更新其版本以匹配
全局需求中列出的条目。过多的条目将在硬模式（默认）下导致
错误，或在软模式下被忽略。
生成约束-p/usr/b in/python2.7-p/usr/bin/python3\-b blacklist.txt-r global-requirements.txt>；new constraints.txt
devstack使用它来启用库的git安装，这些库通常受到限制：：
edit constraints oslo.db"-e file://opt/stack/oslo.db\egg=oslo.db"
它们。
对"global requirements.txt"的所有更改都可能由于添加或删除可传递的依赖关系而显著更改"upper constraints.txt"的内容。因此，您应该始终针对当前合并的约束生成diff，否则，如果更改与当前测试的约束不兼容，则更改可能会失败。
编译各种python包：：
sudo apt get install$（bindep-b）
2）创建一个引用文件（在不应用补丁的情况下执行此操作）：：
generate constraints-p/usr/bin/python2.7-p/usr/bin/python3\
-b blacklist.txt-r global-requirements.txt>；基线
3）应用修补程序并生成新的引用文件：：
generate constraints-p/usr/bin/python2.7-p/usr/bin/python3 \
-b blacklist.txt-r global-requirements.txt>；已更新
4）差异它们：：
diff-p基线已更新
5）应用"upper constraints.txt"的修补程序。这可能需要一些
摆弄。``当更改不涉及一个包的多行时，编辑约束``可以为您**。
建议者可以通过将这些问题的答案包含在提交信息中，从而使评审变得更容易，因为
他们的更改。
一般评审标准
重视上游需求中断的早期反馈，因此除了处理异常不稳定的库时，应避免版本上限。
如果库异常不稳定，我们还应该考虑是否要随着时间的推移用一个稳定的库来替换它，或者帮助上游社区稳定它。如果不知道工作最小值是什么，请查看成功运行devstack/tempest时pip freeze的输出并使用该版本。至少
现在可以工作了。
-提交消息应该引用正在使用的项目
理想情况下，应该已经提出更改，以便可以看到其用途。
-黑名单用于处理不受限制的依赖项。
例如，每个项目具有不同版本级别的linter，
这使得项目在每个版本上都失败（因为它们添加了规则）
除非我们同时协调将所有的openstack更新到新版本上，否则这些不能受到全局限制-但是考虑到志愿者和松散耦合的大帐篷不可行的只在不受约束的地方使用的依赖项不应被列入黑名单-它们在将来可能会受到约束，并且今天约束它们不会造成危害。黑名单中的条目应该有一个注释，解释黑名单的原因。
-只有更新"projects.txt"的评论应该在其他评论旁边或之前获得工作流批准，以便OpenStack提议bot的传播在对其他项目来说是可能的。对于项目
移除或添加，当前ptl的+1（或如果ptl提议
更改，则为核心）应足够。
对于新的需求
----
-库是否得到积极维护？
如果我们或我们的用户发现了一个bug，我们*真的*想知道这个库是我们可以获得支持的，而且我们不需要接管和分叉库。
指向最近上游活动的指针和一致的发布模型是值得赞赏的。
-库代码好吗？
在告诉每个人从互联网上下载任意第三方代码之前，提交者应该已经深入到代码中，以了解该代码是否看起来像足够可靠。这包括确保上游代码有一些合理的测试。
-库python 3兼容吗？
openstack最终需要支持python 3。此时，添加不兼容python 3的库只能在
*extreme*need下完成。这应该被认为是一个非常大的例外。
-库许可证是否兼容？
应按照"许可要求"中的说明对库进行许可，
，并应在与添加的依赖项相同的行上的注释中对许可进行说明。如果您对许可兼容性有疑问，例如在添加gpl测试依赖项时，可以向robert collins（lifeless）寻求建议，monty taylor（mordred）或jim blair（jeblair）。
-这个库是否已经打包在我们的目标发行版中（ubuntu
latest/fedora latest）？
通过在openstack``global requirements.txt``中添加一些内容，我们基本上要求linux发行版在openstack的下一个版本中打包这些内容。如果他们已经有了，太好了。如果没有，我们应该小心添加它。：ref:`finding distro status`
-此库的功能是否已被"global requirements.txt"中的其他库所覆盖？
每个人都有自己喜欢使用的pet库，但是我们不需要openstack中的三个不同的请求模拟库。
然后，我们还需要
转换计划，以便在合理的
时间内删除旧库。
-openstack项目或相关开发或
基础设施设置需要库吗？（当然，答案应该是肯定的）
哪个？
请提供详细信息，例如gerrit更改请求或启动板
指定添加此库需要的bug/blueprint。
-如果库版本由openstack版本进程管理，则它使用"带中间层的循环"版本类型？
这是为了确保使用需求的更新版本
可用于与其他
项目的集成/可安装性测试。
-是否需要更新其他内容？
添加新库时，需要将发行版的初始版本添加到"upper constraints.txt"中。之后，openstack proposal bot将
建议更新。_许可要求：https://governance.openstack.org/tc/reference/licensing.html
用于升级要求版本的
--------------------------
-为什么不可能使用当前版本定义？
每个人都喜欢其他人使用其最新版本的代码。然而，部署人员确实不喜欢不断更新
内容。除非实际上**不可能**使用"global requirements.txt"中指定的最低版本，它不应该被更改。
让部署人员和发行版来决定。
-更新由OpenStack社区开发的库的最低版本的更改可以由一个审阅者批准，只要
约束条件正确且测试通过。
…_ finding-distro-status:
finding-distro-status
---------
来自OpenStack发行版支持策略：
OpenStack将其开发工作瞄准最新的Ubuntu/Fedora，
，但不会引入任何更改，使其无法在最新的ubuntu LTS或最新的RHEL。
s:
-ubuntu-http://packages.ubuntu.com/
-fedora-https://apps.fedora project.org/packages/
-gentoo-https://packages.gentoo.org/
-suse-https://build.opensuse.org/project/show/devel:languages:python
for``upper constraints.txt``如果更改是由openstack ci bot提出的，则如果更改已通过ci，则只需要一个审阅者，而且他们应该+2+a而不必考虑事物。
如果更改不是由openstack ci bot提出的，只有
更改了新库版本的"upper constraints.txt"条目，
如果更改通过了测试，则应予以批准。请参阅openstack/releases中的
readme.rst，以获取有关release
过程的更多详细信息。
然后应该拒绝它：ci
bot本身将生成适当的更改。如果需要更快地运行bot，请在openstack infra中询问。
在这种情况下，忽略对"upper constraints.txt"的更改，并查看更改的
``global requirements.txt``组件。
发布项目。releases
项目确保了有效的稳定版本（很少甚至没有api级别的更改，只有bug
等等）。一旦发布，新版本就需要在
需求中更新。以下限制有助于确保稳定的
分支不会中断。
-在稳定的分支中，我们通常只更新openstack社区中管理的
项目的约束。当
存在浇口问题时，其他项目也有例外。这些更新必须由手工提出。
-需求团队还验证新版本的需求更改
与稳定分支（GR和UC）中的需求一致。
稳定的分支，主要是屏蔽已知的
错误版本，或者极端地增加一个包允许的最大版本。
我们也要删除这些帽。只有在"第一阶段"期间才可以提高有效最低值，而且这只是由于安全问题。
_第一阶段：https://docs.openstack.org/project team guide/stable branches.html；支持阶段
允许这样做的一个例子是：依赖项的依赖项有一个影响openstack的问题。
它没有列在global-requirements.txt中，但它是必需的。为了
阻止受影响的版本并仍然能够保持需求同步，我们在global-requirements.txt中列出库并更新所有需要它的项目。
resources
==
-文档：https://docs.openstack.org/requirements/latest/
-wiki:https://wiki.openstack.org/wiki/requirements
-错误：https://launchpad.net/openstack要求
欢迎加入QQ群-->： 979659372
