openstack 使用pbr配置,setup.cfg的格式与含义

admin · 发表于 2019-10-15 11:32:30

long_description
There is no need to maintain two long descriptions- and your README file is probably a good long_description. So we’ll just inject the contents of your README.rst, README.txt or README file into your empty long_description. Yay for you.

日志描述

没有必要维护两个详细描述-你的README文件就应该是很好的描述。所以我们将你的README.rst，或者README.txt 或者README文件中的内容提取出来，作为项目描述。

Usage
pbr is a setuptools plugin and so to use it you must use setuptools and call setuptools.setup(). While the normal setuptools facilities are available, pbr makes it possible to express them through static data files.

使用

pbr是setuptools的插件，所以你必须使用setuptools，然后调用setuptools.setup()函数。当普通的setuptools设施可用，pbr通过静态的数据文档使得需求被更加清晰表达。

setup.py
pbr only requires a minimal setup.py file compared to a standard setuptools project. This is because most configuration is located in static configuration files. This minimal setup.py file should look something like this:

pbr只需要最小化的setup.py 文件，跟普通的使用setuptools的项目相比。这是因为设置都在setup.cfg里面。setup.py文件如下。

复制代码
#!/usr/bin/env python

from setuptools import setup

setup(
setup_requires=['pbr'],
pbr=True,
)
复制代码

Note

It is necessary to specify pbr=True to enabled pbr functionality.

Note

While one can pass any arguments supported by setuptools to setup(), any conflicting arguments supplied in setup.cfg will take precedence.

注意:
必须设置pbr=True,来使用pbr.

当使用setuptools的setup函数来进行设置时，如果与位于setup.cfg中的信息产生冲突，则setup.cfg则优先。

setup.cfg
The setup.cfg file is an ini-like file that can mostly replace the setup.py file. It is based on the distutils2 setup.cfg file. A simple sample can be found in pbr‘s own setup.cfg (it uses its own machinery to install itself):

setup.cfg文档

这个文档像ini 文档。它基于项目distutils2的setup.cfg文件设置。下面是一个例子(这个设置中项目使用自己的机制去安装)

复制代码
[metadata]
name = pbr
author = OpenStack Foundation
author-email = openstack-dev@lists.openstack.org
summary = OpenStack's setup automation in a reusable form
description-file = README
home-page = https://launchpad.net/pbr
license = Apache-2
classifier =
Development Status :: 4 - Beta
      Environment :: Console
      Environment :: OpenStack
      Intended Audience :: Developers
      Intended Audience :: Information Technology
      License :: OSI Approved :: Apache Software License
      Operating System :: OS Independent
      Programming Language :: Python
keywords =
setup
distutils
[files]
packages =
pbr
data_files =
etc/pbr = etc/*
etc/init =
      pbr.packaging.conf
      pbr.version.conf
[entry_points]
console_scripts =
pbr = pbr.cmd:main
pbr.config.drivers =
plain = pbr.cfg.driver:Plain
复制代码

There are a number of sections in these documents. These are:

metadata
files
entry_points
pbr
setup.cfg文件中有几个段落：
metadata
files
entry_points
pbr

files
The files section defines the install location of files in the package using three fundamental keys: packages, namespace_packages, and data_files.

packages is a list of top-level packages that should be installed. The behavior of packages is similar to setuptools.find_packages in that it recurses the python package hierarchy below the given top level and installs all of it. If packages is not specified, it defaults to the value of the name field given in the [metadata] section.

namespace_packages is the same, but is a list of packages that provide namespace packages.

data_files lists files to be installed. The format is an indented block that contains key value pairs which specify target directory and source file to install there. More than one source file for a directory may be indicated with a further indented list. Source files are stripped of leading directories. Additionally, pbr supports a simple file globbing syntax for installing entire directory structures, thus:

段落 files

files段落定义了包中的文件位置，有三个基本的设置键：packages,namespace_packages,以及data_files.

packages指定了必须安装的数个最高级别的包的列表。这个像setuptools中的函数find_packages.这里面它进入python的包体系中，在最高的级别路径下安装它。如果packages没有被指明，则默认为metadata段落中的name键值。

复制代码
[files]
data_files =
etc/pbr = etc/pbr/*
etc/neutron =
      etc/api-paste.ini
      etc/dhcp-agent.ini
etc/init.d = neutron.init
复制代码

will result in /etc/neutron containing api-paste.ini and dhcp-agent.ini, both of which pbr will expect to find in the etc directory in the root of the source tree. Additionally, neutron.init from that dir will be installed in /etc/init.d. All of the files and directories located under etc/pbr in the source tree will be installed into /etc/pbr.

Note that this behavior is relative to the effective root of the environment into which the packages are installed, so depending on available permissions this could be the actual system-wide /etc directory or just a top-level etc subdirectory of a virtualenv.

上面的配置会将本项目的etc/api-paste.ini拷贝/etc/neutron 文件夹中，而将项目中的etc/pbr中的所有文件拷贝到/etc/pbr中。项目中的neutron.init将会拷贝到/etc/init.d中。
注意:

这种行为是根据在那个环境下包被安装，以及它们相应的根目录。(也就是说拷贝也许不是到/etc/neutron中，或者某个子目录下面的etc/neutron中)。所以基于权限，文件会被拷贝到根目录下的etc或者某个子目录下的etc

entry_points
The entry_points section defines entry points for generated console scripts and python libraries.

The general syntax of specifying entry points is a top level name indicating the entry point group name, followed by one or more key value pairs naming the entry point to be installed. For instance:

段落entry_points

这个段落定义了命令行命令以及python的库lib的进入点。

里面的内容分成子段落，子段落的头行设置了一组进入点的最高级目录的名称，里面定义了键值对，描述了会被安装的进入点。

复制代码
[entry_points]
console_scripts =
pbr = pbr.cmd:main
pbr.config.drivers =
plain = pbr.cfg.driver:Plain
fancy = pbr.cfg.driver:Fancy
复制代码

Will cause a console script called pbr to be installed that executes the main function found in pbr.cmd. Additionally, two entry points will be installed for pbr.config.drivers, one called plain which maps to the Plain class in pbr.cfg.driver and one called fancy which maps to the Fancy class in pbr.cfg.driver.

这段设置会产生一个pbr的脚本，执行pbr.cmd中的main函数，而pbr.config.dirvers则会安装两个进入点，为plain以及fancy。对应Plain,和Fancy函数。

pbr
The pbr section controls pbr specific options and behaviours.

The autodoc_tree_index_modules is a boolean option controlling whether pbr should generate an index of modules using sphinx-apidoc. By default, setup.py is excluded. The list of excluded modules can be specified with the autodoc_tree_excludes option. See the sphinx-apidoc man page for more information.

The autodoc_index_modules is a boolean option controlling whether pbr should itself generates documentation for Python modules of the project. By default, all found Python modules are included; some of them can be excluded by listing them in autodoc_exclude_modules. This list of modules can contains fnmatch style pattern (e.g. myapp.tests.*) to exclude some modules.

The warnerrors boolean option is used to tell Sphinx builders to treat warnings as errors which will cause sphinx-build to fail if it encounters warnings. This is generally useful to ensure your documentation stays clean once you have a good docs build.

pbr

pbr段落控制pbr相关的参数以及行为

autodoct_tree_index_modules 是一个布尔型参数，描述pbr是否应该为sphinx-apidoc中的模块自动产生索引。默认的，setup.py排除在外。可以在autodoc_tree-excludes的设置中设定一系列被排除在外的模块。参考sphinx-apidoc man page 获取更多帮助信息。

autodoc_index_modules是一个布尔型参数,控制pbr是否自己为项目的python模块产生文档。默认的，所以找到的python模块包含在内；他们有些被autodoc_exclude_modules排除掉了。这个排除文件模块列表可以包含fnmatch 风格的设置(例如myapp.tests.*)

warnerrors 是一个布尔型参数，用来告诉sphinx 将警告信息看待为出错信息，如果当它遇到警告就会失败。如果你想让你的文档干净良好这样做很必要。

Note

When using autodoc_tree_excludes or autodoc_index_modules you may also need to set exclude_patterns in your Sphinx configuration file (generally found at doc/source/conf.py in most OpenStack projects) otherwise Sphinx may complain about documents that are not in a toctree. This is especially true if the warnerrors=True option is set. See the Sphinx build configuration file documentation for more information on configuring Sphinx.

注意

当使用autodoc_tree_excludes 或者autodoc_index_modules。你也需要在sphinx的配置文件中设置exclude_patterns(一般在项目中的 /doc/source/conf.py找到)。否则sphinx将会告知文档不在toctree中。当warnerrors=True开启后这个也需要为真。参考Sphinx build configuration file 文档获取更多如何配置sphinx.

Comments
Comments may be used in setup.cfg, however all comments should start with a # and may be on a single line, or in line, with at least one white space character immediately preceding the #. Semicolons are not a supported comment delimiter. For instance:

评论

段落可以设置评论，必须以#开头，#后面紧跟一个空格。

复制代码
[section]
# A comment at the start of a dedicated line
key =
value1 # An in line comment
value2
# A comment on a dedicated line
value3
复制代码

Requirements
Requirement files should be given one of the below names. This order is also the order that the requirements are tried in (where N is the Python major version number used to install the package):

requirements-pyN.txt
tools/pip-requires-py3
requirements.txt
tools/pip-requires
Only the first file found is used to install the list of packages it contains.

Note

The ‘requirements-pyN.txt’ file is deprecated - ‘requirements.txt’ should be universal. You can use Environment markers for this purpose.

项目需求

需求文档必须以以下名字命名。列举顺序也就是python进行尝试时候的顺序。(这里面N代表python安装包时候的主要版本数字)

requirements-pyN.txt
tools/pip-requires-py3
requirements.txt
tools/pip-requires
仅仅第一个文件用来安装所有包
注意

'requirements-pyN.txt'文件不被建议，而‘requirements.txt’是通用格式，你可以参考Environment markers 查看。

Extra requirements
Groups of optional dependencies, or “extra” requirements, can be described in your setup.cfg, rather than needing to be added to setup.py. An example (which also demonstrates the use of environment markers) is shown below.

其他的需求

一组可选的依赖，或者‘额外’的依赖，与其在setup.py中，也可以在setup.cfg中被描述。下面就是一个例子(展示了环境标签的使用)

Environment markers
Environment markers are conditional dependencies which can be added to the requirements (or to a group of extra requirements) automatically, depending on the environment the installer is running in. They can be added to requirements in the requirements file, or to extras defined in setup.cfg, but the format is slightly different for each.

环境标签

环境标签是条件依赖，根据运行环境来设定需求文件。它们可以被加入进requirements文档或者在setup.cfg中定义,但是格式有些微不同。

For requirements.txt:

argparse; python_version=='2.6'

例如在requirements.txt中

argparse; python_version=='2.6'
This will result in the package depending on argparse only if it’s being installed into Python 2.6

For extras specifed in setup.cfg, add an extras section. For instance, to create two groups of extra requirements with additional constraints on the environment, you can use:

这会导致包依赖于argparse包，仅仅当在python2.6的情况下

而在setup.cfg中，在extras段里面，例如，创建依赖环境的两个需求组，你可以使用以下配置：

复制代码
[extras]
security =
aleph
bet:python_version=='3.2'
gimel:python_version=='2.7'
testing =
quux:python_version=='2.7'

		自动登录	找回密码
密码			注册