setuptools.setup() 接受哪些关键字参数？
What keyword arguments does setuptools.setup() accept?
setuptools.setup() 函数接受的关键字参数的完整列表是什么？ （如果可能，请描述每个参数的含义。）
我在整个网络上都看过了，我不敢相信这没有记录在案。
我找到了这些文档：
- https://docs.python.org/3.7/distutils/setupscript.html#additional-meta-data
- https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed-setup-keywords
但即使我将它们结合起来，它们也缺少其他参数，例如
- 脚本
- 包
- 提供
- 已过时
...我不知道还缺少多少参数。
setuptools.setup() 函数接受的关键字参数的完整列表是什么？
setuptools.setup() 调用 distutils.core.setup() 并将它自己的 **kwargs 作为唯一参数传递，因此 distutils 接受的任何关键字也将被 setuptools 接受.如果我们去看看 distutils
setup_keywords = ('distclass', 'script_name', 'script_args',
'options', 'name', 'version', 'author',
'author_email', 'maintainer', 'maintainer_email',
'url', 'license', 'description',
'long_description', 'keywords', 'platforms',
'classifiers', 'download_url', 'requires',
'provides', 'obsoletes',
)
其中大部分都有记录 here but some are not included in the table: packages, package_dir, package_data, scripts, obsoletes, provides, py_modules and data_files。
setup_keywords 元组中也缺少其中一些。如果你 grep for setup_keywords 它看起来不像它实际上在任何地方被引用......但这是另一天的故事。不管怎样，这是 Python 3.10 的（希望是完整的）列表。
distutils.core.setup() 关键字参数
(必需: 名称, version，以及 author 或 maintainer 中的至少一个)
作者：
package author’s name (required if maintainer is not provided)
author_email:
email address of the package author
class厂商：
a list of classifiers (see: https://pypi.org/classifiers/)
The data_files option can be used to specify additional files needed by the module distribution: configuration files, message catalogs, data files, anything which doesn’t fit in the previous categories.
data_files specifies a sequence of (directory, files) pairs in the following way:
setup(...,
data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
('config', ['cfg/data.cfg'])],
)
Each (directory, files) pair in the sequence specifies the installation directory and the files to install there. Each file name in files is interpreted relative to the setup.py script.
描述：
short, summary description of the package
download_url:
location where the package may be downloaded
关键词：
a list of keywords (Also takes a string. If comma separated, it is split into a list)
许可证：
license for the package (Use only if the license is not one listed in the "trove classifiers". See: Classifiers)
long_description:
longer description of the package, used by PyPI to build the project page
维护者：
package maintainer’s name (required if author is not provided)
maintainer_email:
email address of the package maintainer
姓名：
name of the package (required by distutils)
A package can declare that it obsoletes other packages using the obsoletes keyword argument. The value for this is similar to that of the requires keyword: a list of strings giving module or package specifiers. Each specifier consists of a module or package name optionally followed by one or more version qualifiers. Version qualifiers are given in parentheses after the module or package name
Package data can be added to packages using the package_data keyword argument to the setup() function. The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package (information from the package_dir mapping is used if appropriate); that is, the files are expected to be part of the package in the source directories.
If you use a different convention to lay out your source directory, that’s no problem: you just have to supply the package_dir option to tell the Distutils about your convention. For example, say you keep all Python source under lib, so that modules in the “root package” (i.e., not in any package at all) are in lib, modules in the foo package are in lib/foo, and so forth. Then you would put
package_dir = {'': 'lib'}
in your setup script. The keys to this dictionary are package names, and an empty package name stands for the root package. The values are directory names relative to your distribution root. In this case, when you say packages = ['foo'], you are promising that the file lib/foo/__init__.py exists.
Another possible convention is to put the foo package right in lib, the foo.bar package in lib/bar, etc. This would be written in the setup script as
package_dir = {'foo': 'lib'}
A package: dir entry in the package_dir dictionary implicitly applies to all packages below package, so the foo.bar case is automatically handled here. In this example, having packages = ['foo', 'foo.bar'] tells the Distutils to look for lib/__init__.py and lib/bar/__init__.py. (Keep in mind that although package_dir applies recursively, you must explicitly list all packages in packages: the Distutils will not recursively scan your source tree looking for any directory with an __init__.py file.)
Package data can be added to packages using the package_data keyword argument to the setup() function. The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package (information from the package_dir mapping is used if appropriate); that is, the files are expected to be part of the package in the source directories. They may contain glob patterns as well.
平台：
a list of platforms (Also takes a string. If comma separated, it is split into a list)
Now that we can specify dependencies, we also need to be able to specify what we provide that other distributions can require. This is done using the provides keyword argument to setup().
For a small module distribution, you might prefer to list all modules rather than listing packages—especially the case of a single module that goes in the “root package” (i.e., no package at all).
py_modules = ['foo.py']
here is a slightly more involved example:
py_modules = ['mod1', 'pkg.mod2']
This describes two modules, one of them in the “root” package, the other in the pkg package. Again, the default package/directory layout implies that these two modules can be found in mod1.py and pkg/mod2.py, and that pkg/__init__.py exists as well. And again, you can override the package/directory correspondence using the package_dir option.
Scripts are files containing Python source code, intended to be started from the command line. Scripts don’t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word “python”, the Distutils will adjust the first line to refer to the current interpreter location. By default, it is replaced with the current interpreter location. The --executable (or -e) option will allow the interpreter path to be explicitly overridden.
The scripts option simply is a list of files to be handled in this way. From the PyXML setup script:
setup(...,
scripts=['scripts/xmlproc_parse', 'scripts/xmlproc_val']
)
url:
home page for the package
版本：
version of this release (required by distutils)
setuptools.setup() 关键字参数
除了 distutils 所使用的参数之外，setuptools.setup() 将接受更多的参数。
虽然它被称为 "New and Changed Setup Keywords"（对我来说这是一个版本变更日志），但介绍文字说这些是“setup() 的关键字参数[由 setuptools 添加或更改”所以我相信link实际上提供了一个完整的列表。为了完整起见，我将在此处添加它。
(因为setuptools.setup()调用了distutils.core.setup()，相同的参数是必需的：name、version，以及 author 中的至少一个 或 维护者)
convert_2to3_doctests:
List of doctest source files that need to be converted with 2to3. See Supporting both Python 2 and Python 3 with Setuptools for more details.
dependency_links:
A list of strings naming URLs to be searched when satisfying dependencies. These links will be used if needed to install packages specified by setup_requires or tests_require. They will also be written into the egg’s metadata for use by tools like EasyInstall to use when installing an .egg file.
eager_resources:
A list of strings naming resources that should be extracted together, if any of them is needed, or if any C extensions included in the project are imported. This argument is only useful if the project will be installed as a zipfile, and there is a need to have all of the listed resources be extracted to the filesystem as a unit. Resources listed here should be ‘/’-separated paths, relative to the source root, so to list a resource foo.png in package bar.baz, you would include the string bar/baz/foo.png in this argument.
If you only need to obtain resources one at a time, or you don’t have any C extensions that access other files in the project (such as data files or shared libraries), you probably do NOT need this argument and shouldn’t mess with it. For more details on how this argument works, see the section below on Automatic Resource Extraction.
entry_points:
A dictionary mapping entry point group names to strings or lists of strings defining the entry points. Entry points are used to support dynamic discovery of services or plugins provided by a project. See Dynamic Discovery of Services and Plugins for details and examples of the format of this argument. In addition, this keyword is used to support Automatic Script Creation.
exclude_package_data:
A dictionary mapping package names to lists of glob patterns that should be excluded from your package directories. You can use this to trim back any excess files included by include_package_data. For a complete description and examples, see the section below on Including Data Files.
extras_require:
A dictionary mapping names of “extras” (optional features of your project) to strings or lists of strings specifying what other distributions must be installed to support those features. See the section below on Declaring Dependencies for details and examples of the format of this argument.
注意：对于 extras_require 词典，在 54.1.0 之前的版本中，如果在键中使用破折号，则会将其转换为下划线。如果用户使用包含应该使用下划线的破折号的别名（例如 author-email 而不是 author_email），更高版本允许使用破折号并警告用户，并且在这种情况下仍会执行转换。将来这种转换将不再自动完成。
include_package_data:
If set to True, this tells setuptools to automatically include any data files it finds inside your package directories that are specified by your MANIFEST.in file. For more information, see the section below on Including Data Files.
install_requires:
A string or list of strings specifying what other distributions need to be installed when this one is. See the section below on Declaring Dependencies for details and examples of the format of this argument.
namespace_packages:
A list of strings naming the project’s “namespace packages”. A namespace package is a package that may be split across multiple project distributions. For example, Zope 3’s zope package is a namespace package, because subpackages like zope.interface and zope.publisher may be distributed separately. The egg runtime system can automatically merge such subpackages into a single parent package at runtime, as long as you declare them in each project that contains any subpackages of the namespace package, and as long as the namespace package’s __init__.py does not contain any code other than a namespace declaration. See the section below on Namespace Packages for more information.
package_data:
A dictionary mapping package names to lists of glob patterns. For a complete description and examples, see the section below on Including Data Files. You do not need to use this option if you are using include_package_data, unless you need to add e.g. files that are generated by your setup script and build process. (And are therefore not in source control or are files that you don’t want to include in your source distribution.)
project_urls:
An arbitrary map of URL names to hyperlinks, allowing more extensible documentation of where various resources can be found than the simple url and download_url options provide.
python_requires:
A string corresponding to a version specifier (as defined in PEP 440) for the Python version, used to specify the Requires-Python defined in PEP 345.
setup_requires:
A string or list of strings specifying what other distributions need to be present in order for the setup script to run. setuptools will attempt to obtain these (even going so far as to download them using EasyInstall) before processing the rest of the setup script or commands. This argument is needed if you are using distutils extensions as part of your build process; for example, extensions that process setup() arguments and turn them into EGG-INFO metadata files.
(Note: projects listed in setup_requires will NOT be automatically installed on the system where the setup script is being run. They are simply downloaded to the ./.eggs directory if they’re not locally available already. If you want them to be installed, as well as being available when the setup script is run, you should add them to install_requires and setup_requires.)
test_loader:
If you would like to use a different way of finding tests to run than what setuptools normally uses, you can specify a module name and class name in this argument. The named class must be instantiable with no arguments, and its instances must support the loadTestsFromNames() method as defined in the Python unittest module’s TestLoader class. Setuptools will pass only one test “name” in the names argument: the value supplied for the test_suite argument. The loader you specify may interpret this string in any way it likes, as there are no restrictions on what may be contained in a test_suite string.
The module name and class name must be separated by a :. The default value of this argument is setuptools.command.test:ScanningLoader. If you want to use the default unittest behavior, you can specify unittest:TestLoader as your test_loader argument instead. This will prevent automatic scanning of submodules and subpackages.
The module and class you specify here may be contained in another package, as long as you use the tests_require option to ensure that the package containing the loader class is available when the test command is run.
test_suite:
A string naming a unittest.TestCase subclass (or a package or module containing one or more of them, or a method of such a subclass), or naming a function that can be called with no arguments and returns a unittest.TestSuite. If the named suite is a module, and the module has an additional_tests() function, it is called and the results are added to the tests to be run. If the named suite is a package, any submodules and subpackages are recursively added to the overall test suite.
Specifying this argument enables use of the test command to run the specified test suite, e.g. via setup.py test. See the section on the test command below for more details.
tests_require:
If your project’s tests need one or more additional packages besides those needed to install it, you can use this option to specify them. It should be a string or list of strings specifying what other distributions need to be present for the package’s tests to run. When you run the test command, setuptools will attempt to obtain these (even going so far as to download them using EasyInstall). Note that these required projects will not be installed on the system where the tests are run, but only downloaded to the project’s setup directory if they’re not already installed locally.
use_2to3:
Convert the source code from Python 2 to Python 3 with 2to3 during the build process. See Supporting both Python 2 and Python 3 with Setuptools for more details.
By default, the conversion uses all fixers in the lib2to3.fixers package. To use additional fixers, the parameter use_2to3_fixers can be set to a list of names of packages containing fixers. To exclude fixers, the parameter use_2to3_exclude_fixers can be set to fixer names to be skipped.
A list of modules to search for additional fixers to be used during the 2to3 conversion. See Supporting both Python 2 and Python 3 with Setuptools for more details.
zip_safe:
A boolean (True or False) flag specifying whether the project can be safely installed and run from a zip file. If this argument is not supplied, the bdist_egg command will have to analyze all of your project’s contents for possible problems each time it builds an egg.
扩展
构建一个扩展（而不是一个纯粹的 Python 模块）更复杂，因为它本质上要求您指定必要的参数和自变量，以便从 C 源文件成功构建扩展。这是通过 ext_modules 关键字完成的，它只是 Extension 个实例的列表（可从 distutils.core 导入）。 Extension class 构造函数接受的关键字参数是用于指定编译扩展的构建步骤的输入向量。
由于这个问题具体是关于 setuptools.setup()，我将只包括 ext_modules 的定义，但 documentation for the Extension class 提供了完整的细节。为了完整起见，这是 Extension 构造函数接受的关键字列表：
extension_keywords = ('name', 'sources', 'include_dirs',
'define_macros', 'undef_macros',
'library_dirs', 'libraries',
'runtime_library_dirs', 'extra_objects',
'extra_compile_args', 'extra_link_args',
'swig_opts', 'export_symbols', 'depends',
'language')
A list of Extension instances, each of which describes a single extension module. Suppose your distribution includes a single extension, called foo and implemented by foo.c. If no additional instructions to the compiler/linker are needed, describing this extension is quite simple:
from distutils.core import setup, Extension
setup(name='foo',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
)
其他
最后，甚至更多 kwargs 可以在 setuptools.dist 和其他地方实现，但由于某些原因从未添加到任何主要 setuptools/distutils 文档：
功能（已弃用）：
a dictionary mapping option names to setuptools.Feature objects. Features are a portion of the distribution that can be included or excluded based on user options, inter-feature dependencies, and availability on the current system. Excluded features are omitted from all setup commands, including source and binary distributions, so you can create multiple distributions from the same source tree.
long_description_content_type（根据 Making a PyPI-friendly README）：
set to an accepted Content-Type-style value for your README file’s markup, such as text/plain, text/x-rst (for reStructuredText), or text/markdown.
provides_extras（根据 PEP566, listed as "Provides-Extra"）：
A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested.
setuptools.setup() 函数接受的关键字参数的完整列表是什么？ （如果可能，请描述每个参数的含义。）
我在整个网络上都看过了，我不敢相信这没有记录在案。
我找到了这些文档：
- https://docs.python.org/3.7/distutils/setupscript.html#additional-meta-data
- https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed-setup-keywords
但即使我将它们结合起来，它们也缺少其他参数，例如
- 脚本
- 包
- 提供
- 已过时
...我不知道还缺少多少参数。
setuptools.setup() 函数接受的关键字参数的完整列表是什么？
setuptools.setup() 调用 distutils.core.setup() 并将它自己的 **kwargs 作为唯一参数传递，因此 distutils 接受的任何关键字也将被 setuptools 接受.如果我们去看看 distutils
setup_keywords = ('distclass', 'script_name', 'script_args',
'options', 'name', 'version', 'author',
'author_email', 'maintainer', 'maintainer_email',
'url', 'license', 'description',
'long_description', 'keywords', 'platforms',
'classifiers', 'download_url', 'requires',
'provides', 'obsoletes',
)
其中大部分都有记录 here but some are not included in the table: packages, package_dir, package_data, scripts, obsoletes, provides, py_modules and data_files。
setup_keywords 元组中也缺少其中一些。如果你 grep for setup_keywords 它看起来不像它实际上在任何地方被引用......但这是另一天的故事。不管怎样，这是 Python 3.10 的（希望是完整的）列表。
distutils.core.setup() 关键字参数
(必需: 名称, version，以及 author 或 maintainer 中的至少一个)
作者：
package author’s name (required if maintainer is not provided)
author_email:
email address of the package author
class厂商：
a list of classifiers (see: https://pypi.org/classifiers/)
The
data_filesoption can be used to specify additional files needed by the module distribution: configuration files, message catalogs, data files, anything which doesn’t fit in the previous categories.
data_filesspecifies a sequence of(directory, files)pairs in the following way:setup(..., data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']), ('config', ['cfg/data.cfg'])], )Each
(directory, files)pair in the sequence specifies the installation directory and the files to install there. Each file name in files is interpreted relative to thesetup.pyscript.
描述：
short, summary description of the package
download_url:
location where the package may be downloaded
关键词：
a list of keywords (Also takes a string. If comma separated, it is split into a list)
许可证：
license for the package (Use only if the license is not one listed in the "trove classifiers". See: Classifiers)
long_description:
longer description of the package, used by PyPI to build the project page
维护者：
package maintainer’s name (required if author is not provided)
maintainer_email:
email address of the package maintainer
姓名：
name of the package (required by
distutils)
A package can declare that it obsoletes other packages using the
obsoleteskeyword argument. The value for this is similar to that of therequireskeyword: a list of strings giving module or package specifiers. Each specifier consists of a module or package name optionally followed by one or more version qualifiers. Version qualifiers are given in parentheses after the module or package name
Package data can be added to packages using the
package_datakeyword argument to thesetup()function. The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package (information from thepackage_dirmapping is used if appropriate); that is, the files are expected to be part of the package in the source directories.
If you use a different convention to lay out your source directory, that’s no problem: you just have to supply the
package_diroption to tell the Distutils about your convention. For example, say you keep all Python source underlib, so that modules in the “root package” (i.e., not in any package at all) are inlib, modules in thefoopackage are inlib/foo, and so forth. Then you would putpackage_dir = {'': 'lib'}in your setup script. The keys to this dictionary are package names, and an empty package name stands for the root package. The values are directory names relative to your distribution root. In this case, when you say
packages = ['foo'], you are promising that the filelib/foo/__init__.pyexists.Another possible convention is to put the
foopackage right inlib, thefoo.barpackage inlib/bar, etc. This would be written in the setup script aspackage_dir = {'foo': 'lib'}A
package: direntry in thepackage_dirdictionary implicitly applies to all packages below package, so thefoo.barcase is automatically handled here. In this example, havingpackages = ['foo', 'foo.bar']tells the Distutils to look forlib/__init__.pyandlib/bar/__init__.py. (Keep in mind that althoughpackage_dirapplies recursively, you must explicitly list all packages in packages: the Distutils will not recursively scan your source tree looking for any directory with an__init__.pyfile.)
Package data can be added to packages using the
package_datakeyword argument to thesetup()function. The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package (information from thepackage_dirmapping is used if appropriate); that is, the files are expected to be part of the package in the source directories. They may contain glob patterns as well.
平台：
a list of platforms (Also takes a string. If comma separated, it is split into a list)
Now that we can specify dependencies, we also need to be able to specify what we provide that other distributions can require. This is done using the
provideskeyword argument tosetup().
For a small module distribution, you might prefer to list all modules rather than listing packages—especially the case of a single module that goes in the “root package” (i.e., no package at all).
py_modules = ['foo.py']here is a slightly more involved example:
py_modules = ['mod1', 'pkg.mod2']This describes two modules, one of them in the “root” package, the other in the
pkgpackage. Again, the default package/directory layout implies that these two modules can be found inmod1.pyandpkg/mod2.py, and thatpkg/__init__.pyexists as well. And again, you can override the package/directory correspondence using thepackage_diroption.
Scripts are files containing Python source code, intended to be started from the command line. Scripts don’t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with
#!and contains the word “python”, the Distutils will adjust the first line to refer to the current interpreter location. By default, it is replaced with the current interpreter location. The--executable (or-e) option will allow the interpreter path to be explicitly overridden.The scripts option simply is a list of files to be handled in this way. From the PyXML setup script:
setup(..., scripts=['scripts/xmlproc_parse', 'scripts/xmlproc_val'] )
url:
home page for the package
版本：
version of this release (required by
distutils)
setuptools.setup() 关键字参数
除了 distutils 所使用的参数之外，setuptools.setup() 将接受更多的参数。
虽然它被称为 "New and Changed Setup Keywords"（对我来说这是一个版本变更日志），但介绍文字说这些是“setup() 的关键字参数[由 setuptools 添加或更改”所以我相信link实际上提供了一个完整的列表。为了完整起见，我将在此处添加它。
(因为setuptools.setup()调用了distutils.core.setup()，相同的参数是必需的：name、version，以及 author 中的至少一个 或 维护者)
convert_2to3_doctests:
List of doctest source files that need to be converted with
2to3. See Supporting both Python 2 and Python 3 with Setuptools for more details.
dependency_links:
A list of strings naming URLs to be searched when satisfying dependencies. These links will be used if needed to install packages specified by
setup_requiresortests_require. They will also be written into the egg’s metadata for use by tools like EasyInstall to use when installing an .egg file.
eager_resources:
A list of strings naming resources that should be extracted together, if any of them is needed, or if any C extensions included in the project are imported. This argument is only useful if the project will be installed as a zipfile, and there is a need to have all of the listed resources be extracted to the filesystem as a unit. Resources listed here should be ‘/’-separated paths, relative to the source root, so to list a resource
foo.pngin packagebar.baz, you would include the stringbar/baz/foo.pngin this argument. If you only need to obtain resources one at a time, or you don’t have any C extensions that access other files in the project (such as data files or shared libraries), you probably do NOT need this argument and shouldn’t mess with it. For more details on how this argument works, see the section below on Automatic Resource Extraction.
entry_points:
A dictionary mapping entry point group names to strings or lists of strings defining the entry points. Entry points are used to support dynamic discovery of services or plugins provided by a project. See Dynamic Discovery of Services and Plugins for details and examples of the format of this argument. In addition, this keyword is used to support Automatic Script Creation.
exclude_package_data:
A dictionary mapping package names to lists of glob patterns that should be excluded from your package directories. You can use this to trim back any excess files included by include_package_data. For a complete description and examples, see the section below on Including Data Files.
extras_require:
A dictionary mapping names of “extras” (optional features of your project) to strings or lists of strings specifying what other distributions must be installed to support those features. See the section below on Declaring Dependencies for details and examples of the format of this argument.
注意：对于 extras_require 词典，在 54.1.0 之前的版本中，如果在键中使用破折号，则会将其转换为下划线。如果用户使用包含应该使用下划线的破折号的别名（例如 author-email 而不是 author_email），更高版本允许使用破折号并警告用户，并且在这种情况下仍会执行转换。将来这种转换将不再自动完成。
include_package_data:
If set to True, this tells setuptools to automatically include any data files it finds inside your package directories that are specified by your MANIFEST.in file. For more information, see the section below on Including Data Files.
install_requires:
A string or list of strings specifying what other distributions need to be installed when this one is. See the section below on Declaring Dependencies for details and examples of the format of this argument.
namespace_packages:
A list of strings naming the project’s “namespace packages”. A namespace package is a package that may be split across multiple project distributions. For example, Zope 3’s
zopepackage is a namespace package, because subpackages likezope.interfaceandzope.publishermay be distributed separately. The egg runtime system can automatically merge such subpackages into a single parent package at runtime, as long as you declare them in each project that contains any subpackages of the namespace package, and as long as the namespace package’s__init__.pydoes not contain any code other than a namespace declaration. See the section below on Namespace Packages for more information.
package_data:
A dictionary mapping package names to lists of glob patterns. For a complete description and examples, see the section below on Including Data Files. You do not need to use this option if you are using include_package_data, unless you need to add e.g. files that are generated by your setup script and build process. (And are therefore not in source control or are files that you don’t want to include in your source distribution.)
project_urls:
An arbitrary map of URL names to hyperlinks, allowing more extensible documentation of where various resources can be found than the simple url and download_url options provide.
python_requires:
A string corresponding to a version specifier (as defined in PEP 440) for the Python version, used to specify the Requires-Python defined in PEP 345.
setup_requires:
A string or list of strings specifying what other distributions need to be present in order for the setup script to run. setuptools will attempt to obtain these (even going so far as to download them using EasyInstall) before processing the rest of the setup script or commands. This argument is needed if you are using distutils extensions as part of your build process; for example, extensions that process
setup()arguments and turn them into EGG-INFO metadata files. (Note: projects listed insetup_requireswill NOT be automatically installed on the system where the setup script is being run. They are simply downloaded to the./.eggsdirectory if they’re not locally available already. If you want them to be installed, as well as being available when the setup script is run, you should add them toinstall_requiresandsetup_requires.)
test_loader:
If you would like to use a different way of finding tests to run than what setuptools normally uses, you can specify a module name and class name in this argument. The named class must be instantiable with no arguments, and its instances must support the
loadTestsFromNames()method as defined in the Pythonunittestmodule’sTestLoaderclass. Setuptools will pass only one test “name” in thenamesargument: the value supplied for thetest_suiteargument. The loader you specify may interpret this string in any way it likes, as there are no restrictions on what may be contained in atest_suitestring. The module name and class name must be separated by a:. The default value of this argument issetuptools.command.test:ScanningLoader. If you want to use the defaultunittestbehavior, you can specifyunittest:TestLoaderas yourtest_loaderargument instead. This will prevent automatic scanning of submodules and subpackages. The module and class you specify here may be contained in another package, as long as you use the tests_require option to ensure that the package containing the loader class is available when the test command is run.
test_suite:
A string naming a
unittest.TestCasesubclass (or a package or module containing one or more of them, or a method of such a subclass), or naming a function that can be called with no arguments and returns aunittest.TestSuite. If the named suite is a module, and the module has anadditional_tests()function, it is called and the results are added to the tests to be run. If the named suite is a package, any submodules and subpackages are recursively added to the overall test suite. Specifying this argument enables use of the test command to run the specified test suite, e.g. viasetup.pytest. See the section on the test command below for more details.
tests_require:
If your project’s tests need one or more additional packages besides those needed to install it, you can use this option to specify them. It should be a string or list of strings specifying what other distributions need to be present for the package’s tests to run. When you run the test command, setuptools will attempt to obtain these (even going so far as to download them using EasyInstall). Note that these required projects will not be installed on the system where the tests are run, but only downloaded to the project’s setup directory if they’re not already installed locally.
use_2to3:
Convert the source code from Python 2 to Python 3 with
2to3during the build process. See Supporting both Python 2 and Python 3 with Setuptools for more details.
By default, the conversion uses all fixers in the
lib2to3.fixerspackage. To use additional fixers, the parameteruse_2to3_fixerscan be set to a list of names of packages containing fixers. To exclude fixers, the parameteruse_2to3_exclude_fixerscan be set to fixer names to be skipped.
A list of modules to search for additional fixers to be used during the
2to3conversion. See Supporting both Python 2 and Python 3 with Setuptools for more details.
zip_safe:
A boolean (True or False) flag specifying whether the project can be safely installed and run from a zip file. If this argument is not supplied, the
bdist_eggcommand will have to analyze all of your project’s contents for possible problems each time it builds an egg.
扩展
构建一个扩展（而不是一个纯粹的 Python 模块）更复杂，因为它本质上要求您指定必要的参数和自变量，以便从 C 源文件成功构建扩展。这是通过 ext_modules 关键字完成的，它只是 Extension 个实例的列表（可从 distutils.core 导入）。 Extension class 构造函数接受的关键字参数是用于指定编译扩展的构建步骤的输入向量。
由于这个问题具体是关于 setuptools.setup()，我将只包括 ext_modules 的定义，但 documentation for the Extension class 提供了完整的细节。为了完整起见，这是 Extension 构造函数接受的关键字列表：
extension_keywords = ('name', 'sources', 'include_dirs',
'define_macros', 'undef_macros',
'library_dirs', 'libraries',
'runtime_library_dirs', 'extra_objects',
'extra_compile_args', 'extra_link_args',
'swig_opts', 'export_symbols', 'depends',
'language')
A list of Extension instances, each of which describes a single extension module. Suppose your distribution includes a single extension, called foo and implemented by foo.c. If no additional instructions to the compiler/linker are needed, describing this extension is quite simple:
from distutils.core import setup, Extension setup(name='foo', version='1.0', ext_modules=[Extension('foo', ['foo.c'])], )
其他
最后，甚至更多 kwargs 可以在 setuptools.dist 和其他地方实现，但由于某些原因从未添加到任何主要 setuptools/distutils 文档：
功能（已弃用）：
a dictionary mapping option names to
setuptools.Featureobjects. Features are a portion of the distribution that can be included or excluded based on user options, inter-feature dependencies, and availability on the current system. Excluded features are omitted from all setup commands, including source and binary distributions, so you can create multiple distributions from the same source tree.
long_description_content_type（根据 Making a PyPI-friendly README）：
set to an accepted Content-Type-style value for your README file’s markup, such as
text/plain,text/x-rst(for reStructuredText), ortext/markdown.
provides_extras（根据 PEP566, listed as "Provides-Extra"）：
A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested.