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',
)
これらのほとんどはここに記載されていますが、パッケージ、package_dir、package_data、scripts、obsoletes、proviodes、py_modules、data_filesの一部は表に含まれていません。
これらの一部はsetup_keywordsタプルにもありません。そして、あなたがsetup_keywordsそれをgrepした場合、実際にはどこにも参照されていないように見えます...しかし、それは別の日の話です。とにかく、ここに（うまくいけば完全な）リストがあります。
distutils.core.setup（）キーワード引数
（必須：名前、バージョン、および少なくとも作成者または保守者の 1人）
著者：
パッケージ作成者の名前（メンテナが提供されていない場合は必須）
author_email：
パッケージ作成者のメールアドレス
分類子：
リスト分類のは、（参照：https://pypi.org/classifiers/）
data_files：
このdata_filesオプションを使用して、モジュールの配布に必要な追加のファイルを指定できます：構成ファイル、メッセージカタログ、データファイル、前のカテゴリに当てはまらないもの。
data_files(directory, files)次の方法でペアのシーケンスを指定します。
setup(...,
data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
('config', ['cfg/data.cfg'])],
)
(directory, files)シーケンスの各ペアは、インストールディレクトリとそこにインストールするファイルを指定します。files内の各ファイル名は、setup.pyスクリプトに関連して解釈されます。
説明：
パッケージの短い要約説明
download_url：
パッケージをダウンロードできる場所
キーワード：
キーワードのリスト（文字列も取ります。カンマで区切られている場合は、リストに分割されます）
ライセンス：
パッケージのライセンス（ライセンスが「trove分類子」にリストされていない場合にのみ使用してください。参照：分類子）
長い説明：
PyPIがプロジェクトページを構築するために使用するパッケージの長い説明
メンテナー：
パッケージメンテナの名前（作者が提供されていない場合は必須）
maintainer_email：
パッケージメンテナーのメールアドレス
名前：
パッケージの名前（が必要distutils）
廃止：
パッケージは、obsoletesキーワード引数を使用して、他のパッケージが廃止されていることを宣言できます。この値はrequiresキーワードの値に似ています。モジュールまたはパッケージ指定子を与える文字列のリストです。各指定子は、モジュール名またはパッケージ名で構成され、オプションで1つ以上のバージョン修飾子が後に続きます。バージョン修飾子は、モジュールまたはパッケージ名の後の括弧内に示されています
package_data：
関数のpackage_dataキーワード引数を使用して、パッケージデータをパッケージに追加できますsetup()。値は、パッケージ名から、パッケージにコピーする必要のある相対パス名のリストへのマッピングでなければなりません。パスは、パッケージを含むディレクトリへの相対パスとして解釈されます（package_dirマッピングからの情報が適切に使用されます）。つまり、ファイルはソースディレクトリのパッケージの一部であることが期待されます。
package_dir：
別の規則を使用してソースディレクトリをレイアウトする場合は、問題ありませんpackage_dir。Distutilsに規則について通知するオプションを指定するだけです。たとえば、すべてのPythonソースをの下に置いてlib、「ルートパッケージ」内のモジュール（つまり、どのパッケージ内にもない）がにありlib、fooパッケージ内のモジュールがにあるlib/foo、などとします。その後、あなたは置くでしょう
package_dir = {'': 'lib'}
設定スクリプトで。このディクショナリのキーはパッケージ名であり、空のパッケージ名はルートパッケージを表します。値は、ディストリビューションルートに関連するディレクトリ名です。この場合、と言うときpackages = ['foo']、ファイルlib/foo/__init__.pyが存在することを約束しています。
別の可能な規則は入れてあるfoo右のパッケージをlib、foo.barパッケージlib/barこれは、とセットアップスクリプトで記述されたことになるなど、
package_dir = {'foo': 'lib'}
ディクショナリのpackage: dirエントリはpackage_dirパッケージの下のすべてのパッケージに暗黙的に適用されるため、foo.barケースはここで自動的に処理されます。この例では、有するpackages = ['foo', 'foo.bar']探すためにDistutilsのを伝えますlib/__init__.pyとlib/bar/__init__.py。（package_dir再帰的に適用されますが、パッケージ内のすべてのパッケージを明示的にリストする必要があることに注意してください。Distutilsは、__init__.pyファイルのあるディレクトリを探すソースツリーを再帰的にスキャンしません。）
パッケージ：
関数のpackage_dataキーワード引数を使用して、パッケージデータをパッケージに追加できますsetup()。値は、パッケージ名から、パッケージにコピーする必要のある相対パス名のリストへのマッピングでなければなりません。パスは、パッケージを含むディレクトリへの相対パスとして解釈されます（package_dirマッピングからの情報が適切に使用されます）。つまり、ファイルはソースディレクトリのパッケージの一部であることが期待されます。それらには、globパターンも含まれる場合があります。
プラットフォーム：
プラットフォームのリスト（文字列も取ります。カンマで区切られている場合は、リストに分割されます）
提供します：
依存関係を指定できるようになったので、他のディストリビューションが必要とするものを提供できるようにする必要もあります。これは、providesキーワード引数を使用して行われますsetup()。
py_modules：
小さなモジュール配布では、パッケージをリストするよりもすべてのモジュールをリストするほうがよい場合があります。特に、「ルートパッケージ」に含まれる単一のモジュールの場合（つまり、パッケージがまったくない場合）。
py_modules = ['foo.py']
これはもう少し複雑な例です：
py_modules = ['mod1', 'pkg.mod2']
これは2つのモジュールを記述し、1つは「ルート」パッケージに、もう1つはパッケージにありpkgます。繰り返しますが、デフォルトのパッケージ/ディレクトリレイアウトは、これらの2つのモジュールがとにmod1.pyありpkg/mod2.py、それもpkg/__init__.py存在することを意味します。また、package_dirオプションを使用してパッケージ/ディレクトリの対応を上書きできます。
スクリプト：
スクリプトは、コマンドラインから起動することを目的としたPythonソースコードを含むファイルです。スクリプトは、非常に複雑なことをするためにDistutilsを必要としません。唯一の賢い機能は、スクリプトの最初の行が#!「python」で始まり、含まれている場合、Distutilsが現在のインタープリターの場所を参照するように最初の行を調整することです。デフォルトでは、現在のインタープリターの場所に置き換えられます。--実行ファイル（または-e）オプションはインタプリタのパスを明示的に上書きできるようになります。
スクリプトオプションは、この方法で処理されるファイルのリストです。PyXMLセットアップスクリプトから：
setup(...,
scripts=['scripts/xmlproc_parse', 'scripts/xmlproc_val']
)
url：
パッケージのホームページ
バージョン：
このリリースのバージョン（が必要distutils）
setuptools.setup（）キーワード引数
がsetuptools.setup()使用する引数以外にも、受け入れる引数がさらにありますdistutils。
これは「新規および変更されたセットアップキーワード」（バージョン変更ログを示唆している）と呼ばれていますが、イントロテキストは、これらが「setuptoolsによって追加または変更されたsetup（）へのキーワード引数」であるため、リンクが実際に提供すると信じています完全なリスト。完全を期すためにここに追加します。
（setuptools.setup()呼び出し以降distutils.core.setup()、同じパラメーターが必要です：名前、バージョン、および作成者または保守者の少なくとも1つ）
convert_2to3_doctests：
2to3で変換する必要があるdoctestソースファイルのリスト。詳細については、SetuptoolsによるPython 2とPython 3の両方のサポートを参照してください。
dependency_links：
依存関係を満たすときに検索されるURLを命名する文字列のリスト。これらのリンクは、setup_requiresまたはtests_requireで指定されたパッケージをインストールする必要がある場合に使用されます。また、EasyInstallなどのツールが.eggファイルをインストールするときに使用するために、卵のメタデータに書き込まれます。
eager_resources：
それらのいずれかが必要な場合、またはプロジェクトに含まれているC拡張機能がインポートされている場合に、一緒に抽出する必要があるリソースに名前を付ける文字列のリスト。この引数は、プロジェクトがzipファイルとしてインストールされ、リストされているすべてのリソースを1つの単位としてファイルシステムに抽出する必要がある場合にのみ役立ちます。ここにリストされているリソースは、ソースルートを基準にした「/」で区切られたパスである必要があります。したがって、パッケージbar.bazにリソースfoo.pngをリストするには、この引数に文字列bar / baz / foo.pngを含めます。リソースを一度に1つずつ取得する必要がある場合、またはプロジェクト内の他のファイル（データファイルや共有ライブラリなど）にアクセスするC拡張がない場合は、おそらくこの引数は不要であり、混乱させるべきではありません。それと。この引数の機能の詳細については、
entry_points：
エントリポイントグループ名を文字列またはエントリポイントを定義する文字列のリストにマッピングする辞書。エントリポイントは、プロジェクトによって提供されるサービスまたはプラグインの動的な検出をサポートするために使用されます。この引数の形式の詳細と例については、サービスとプラグインの動的検出を参照してください。さらに、このキーワードは、自動スクリプト作成をサポートするために使用されます。
exclude_package_data：
パッケージ名をパッケージディレクトリから除外する必要があるグロブパターンのリストにマッピングする辞書。これを使用して、include_package_dataに含まれている余分なファイルを削除できます。完全な説明と例については、以下のデータファイルのインクルードに関するセクションを参照してください。
extras_require：
「extras」（プロジェクトのオプション機能）の名前を文字列または文字列のリストにマッピングした辞書で、これらの機能をサポートするためにインストールする必要がある他のディストリビューションを指定します。この引数の形式の詳細と例については、依存関係の宣言に関する以下のセクションを参照してください。
include_package_data：
これをTrueに設定すると、MANIFEST.inファイルで指定されているパッケージディレクトリ内にあるデータファイルを自動的に含めるようにsetuptoolsに指示します。詳細については、以下のデータファイルのインクルードに関するセクションを参照してください。
install_requires：
このディストリビューションの場合、インストールする必要がある他のディストリビューションを指定する文字列または文字列のリスト。この引数の形式の詳細と例については、依存関係の宣言に関する以下のセクションを参照してください。
namespace_packages：
プロジェクトの「名前空間パッケージ」に名前を付ける文字列のリスト。名前空間パッケージは、複数のプロジェクトディストリビューションに分割できるパッケージです。たとえば、Zope 3のzopeパッケージは名前空間パッケージです。これは、zope.interfaceやzope.publisherなどのサブパッケージが個別に配布される可能性があるためです。eggランタイムシステムは、名前空間パッケージのサブパッケージを含む各プロジェクトで宣言し、名前空間パッケージのinit .pyにコードが含まれていない限り、実行時にそのようなサブパッケージを単一の親パッケージに自動的にマージできます。名前空間宣言以外。詳細については、以下の名前空間パッケージに関するセクションを参照してください。
package_data：
パッケージ名をグロブパターンのリストにマッピングする辞書。完全な説明と例については、以下のデータファイルのインクルードに関するセクションを参照してください。include_package_dataを使用している場合は、このオプションを使用する必要はありません。たとえば、セットアップスクリプトとビルドプロセスによって生成されたファイルを追加する必要がある場合を除きます。（したがって、ソース管理に含まれていないか、ソース配布に含めたくないファイルです。）
project_urls：
ハイパーリンクへのURL名の任意のマップ。これにより、単純なurlおよびdownload_urlオプションが提供するよりも、さまざまなリソースがどこにあるかについての拡張可能なドキュメントが可能になります。
python_requires：
PEP 345で定義されたRequires-Pythonを指定するために使用される、Pythonバージョンのバージョン指定子（PEP 440で定義されたもの）に対応する文字列。
setup_requires：
セットアップスクリプトを実行するために必要な他のディストリビューションを指定する文字列または文字列のリスト。setuptoolsは、残りのセットアップスクリプトまたはコマンドを処理する前に、これらを取得しようとします（EasyInstallを使用してダウンロードする場合でも）。この引数は、ビルドプロセスの一部としてdistutils拡張機能を使用している場合に必要です。たとえば、setup（）引数を処理してEGG-INFOメタデータファイルに変換する拡張機能。（注：setup_requiresにリストされているプロジェクトは、セットアップスクリプトが実行されているシステムに自動的にインストールされません。ローカルで利用できない場合は、単に./.eggsディレクトリにダウンロードされます。インストールする場合は、 、セットアップスクリプトの実行時に利用できるほか、それらをinstall_requiresとsetup_requiresに追加する必要があります。
test_loader：
setuptoolsが通常使用するテストとは異なる方法でテストを検索する場合は、この引数でモジュール名とクラス名を指定できます。名前付きクラスは引数なしでインスタンス化可能でなければならず、そのインスタンスはPythonユニットテストモジュールのTestLoaderクラスで定義されているloadTestsFromNames（）メソッドをサポートする必要があります。Setuptoolsは、names引数で1つのテスト「name」のみを渡します。test_suite引数に指定された値。指定したローダーは、test_suite文字列に何が含まれるかについての制限がないため、この文字列を任意の方法で解釈できます。モジュール名とクラス名は、：で区切る必要があります。この引数のデフォルト値は「setuptools.command.test：ScanningLoader」です。デフォルトの単体テスト動作を使用する場合は、「unittest：TestLoader」を指定できます 代わりにtest_loader引数として。これにより、サブモジュールおよびサブパッケージの自動スキャンが防止されます。ここで指定するモジュールとクラスは、tests_requireオプションを使用して、テストコマンドの実行時にローダークラスを含むパッケージが利用可能であることを確認している限り、別のパッケージに含まれている場合があります。
test_suite：
unittest.TestCaseサブクラス（またはそれらの1つ以上を含むパッケージまたはモジュール、またはそのようなサブクラスのメソッド）を指定する文字列、または引数なしで呼び出すことができ、unittest.TestSuiteを返す関数を指定する文字列。名前付きスイートがモジュールであり、モジュールにadditional_tests（）関数がある場合、それが呼び出され、実行するテストに結果が追加されます。名前付きスイートがパッケージの場合、すべてのサブモジュールとサブパッケージがテストスイート全体に再帰的に追加されます。この引数を指定すると、テストコマンドを使用して、指定したテストスイートを実行できます（例：setup.py test）。詳細については、以下のtestコマンドのセクションを参照してください。
tests_require：
プロジェクトのテストで、インストールに必要なパッケージ以外に1つ以上の追加パッケージが必要な場合は、このオプションを使用してそれらを指定できます。これは、パッケージのテストを実行するために必要な他のディストリビューションを指定する文字列または文字列のリストである必要があります。testコマンドを実行すると、setuptoolsはこれらを取得しようとします（EasyInstallを使用してダウンロードするまでも）。これらの必要なプロジェクトは、テストが実行されるシステムにはインストールされず、ローカルにインストールされていない場合にのみプロジェクトのセットアップディレクトリにダウンロードされることに注意してください。
use_2to3：
ビルドプロセス中に、2to3を使用してソースコードをPython 2からPython 3に変換します。詳細については、SetuptoolsによるPython 2とPython 3の両方のサポートを参照してください。
use_2to3_exclude_fixers：
デフォルトでは、変換ではlib2to3.fixersパッケージ内のすべてのフィクサーが使用されます。追加のフィクサーを使用するには、フィクサーuse_2to3_fixersを含むパッケージの名前のリストにパラメーターを設定できます。フィクサーを除外するには、パラメーターuse_2to3_exclude_fixersをスキップするフィクサー名に設定できます。
use_2to3_fixers：
2to3変換中に使用される追加のフィクサーを検索するためのモジュールのリスト。詳細については、SetuptoolsによるPython 2とPython 3の両方のサポートを参照してください。
zip_safe：
プロジェクトを安全にインストールしてzipファイルから実行できるかどうかを指定するブール（TrueまたはFalse）フラグ。この引数が指定されていない場合、bdist_eggコマンドは、プロジェクトが卵を作成するたびに、問題の可能性についてプロジェクトのすべてのコンテンツを分析する必要があります。
拡張
（純粋なPythonモジュールではなく）拡張機能の構築は、Cソースファイルから拡張機能を正常に構築するために必要なパラメーターと引数を指定する必要があるため、より複雑です。これは、ext_modulesキーワードから実行されます。これはExtensionインスタンスのリストにすぎません（からインポート可能distutils.core）。Extensionクラスコンストラクターが受け入れるキーワード引数は、拡張機能をコンパイルするためのビルドステップを指定するための入力ベクトルです。
この質問はsetuptools.setup()具体的なものであるため、の定義のみを含めますが、クラスext_modulesのドキュメントにExtension詳細が記載されています。完全を期すために、これは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')
ext_modules：
それぞれが単一の拡張モジュールを記述する拡張インスタンスのリスト。ディストリビューションに、fooと呼ばれ、foo.cによって実装される単一の拡張機能が含まれているとします。コンパイラ/リンカーへの追加の指示が必要ない場合、この拡張機能の説明は非常に簡単です。
from distutils.core import setup, Extension
setup(name='foo',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
)
その他
最後に、他の場所や他の場所に実装されているkwargs がさらにsetuptools.distありますが、何らかの理由でメインのsetuptools / distutilsドキュメントに追加されていません。
機能（非推奨）：
'setuptools.Feature'オブジェクトへのオプションマッピングオプション名。機能はディストリビューションの一部であり、ユーザーオプション、機能間の依存関係、および現在のシステムでの可用性に基づいて、追加または除外できます。除外された機能は、ソースおよびバイナリ配布を含むすべてのセットアップコマンドから省略されているため、同じソースツリーから複数の配布を作成できます。
long_description_content_type（"PyPI対応のREADMEを作成する"あたり）：
READMEファイルのマークアップに受け入れられるContent-Typeスタイルの値（text / plain、text / x-rst（reStructuredTextの場合）、text / markdownなど）に設定します。
provides_extras（パー"-提供エクストラ"として記載されているPEP566、 ）：
オプション機能の名前を含む文字列。有効なPython識別子である必要があります。オプション機能が要求されているかどうかに依存する依存関係を作成するために使用できます。