なぜクリックするのですか。

コマンドライン実用プログラムを作成するためのライブラリがこんなにたくさんあります；なぜClickはまだ存在しているのですか？

この質問は簡単に答えられます：Pythonのためのコマンドラインユーティリティは、以下のボックスを選択していないからです。

• 制限されず怠惰に沈着する

• Unix/POSIXコマンドライン約束の実行をサポート

• サポート開箱すなわち用地が環境変数から値をロードする

• カスタム値提示のサポート

• 完全に安定して組み合わせられています

• 開箱用のファイル処理をサポートしております

• 有用な常用アシスタント(端子サイズ、ANSI色の取得、直接キーボード入力の取得、画面のクリア、構成経路の検索、アプリケーションやエディタの起動など)

Clickには多くの代替案がある；明らかなことは optparse そして argparse 標準ライブラリから来ました。他に共感できるものがあるかどうか見てみましょう

Clickは実際に自分のパラメータ解析を実現して使用しませんでした optparse あるいは…。 argparse 従う optparse 行動を解析する。これが根本的なものではないのは argparse それは…… argparse 設計上正確な入れ子命令は許されず，POSIXに適合するパラメータ処理にはいくつかの欠陥がある.

Clickのデザインは面白くてカスタマイズできますが、柔軟すぎることはありません。たとえば，ヘルプページのカスタマイズ可能性が制限される.この制約は意図的であり，Clickは複数のClickインスタンスが直列に接続されたときに期待どおりに動作し続けることを約束しているからである.

あまりにも多くのカスタマイズ可能性がこの約束を破壊するだろう。

CLICKを作成したのは Flask これは，必要な機能を提供するツールが何もないためである.

Clickのすべてを理解するためには、確認することを強くお勧めします 複雑なアプリケーション 章です。

なぜArgparseではないのですか？

内部でクリックしてベースにします optparse ではなく argparse それがそうです。これはユーザが関心を持たない実現詳細である.Clickはargparseに基づいていません。いくつかのアクションによって任意のコマンドラインインタフェースを処理することが困難になります。

• Argparseは、何かがパラメータかオプションかを推測する内蔵された行為を持っている。これは，不完全な命令行を扱う際に問題となり，命令行を完全に知らない場合には，行動が予測不可能になる.これはClickがサブ解析器に割り当てられた野心に反する。

• Argparseは分散を無効にするパラメータをサポートしていません。この機能がなければ，Clickの入れ子解析を安全に実現することは不可能である.

どうしてDocoptなどではありませんか？

Docoptや多くの類似したツールは動作方式的にクールであるが，これらのツールの中にはClickのように命令ネストや組合せ可能なものを扱うことは少ない.開発者によると、Clickは、システム自体がサポートしているアプリケーション統合可能レベルを超えたPythonライブラリを作成することを目的とした最初のPythonライブラリです。

たとえば，Docoptはあなたのヘルプページを解析し，これらのルールに基づいて解析を行う.このような副作用は，docoptがコマンドラインインタフェースを扱う方式にかなり厳しいことである.Docoptの利点は、ヘルプページをうまく制御できるようにすることです。現在の端末幅で出力を再包装できないという欠点があり、翻訳が困難になります。最も重要なのは，docoptは基本解析に限られていることである.これは、パラメータスケジューリングおよびコールバック呼び出しまたはタイプを扱わない。これは，基本的なヘルプページに加えて，解析結果を扱うために大量のコードを作成する必要があることを意味する.

しかし、最も重要なのは、それが結合可能性を困難にすることだ。Docoptは、サブコマンドへの割り当てをサポートするが、例えば、利用可能なコンテンツに基づく任意のタイプの自動サブコマンドを直接サポートしないか、またはサブコマンドを一貫した方法で動作させない。

これはいいですが、これはClickが望んでいる働き方とは違います。クリックは、以下の操作を実行することによって、完全に組み合わせ可能なコマンドラインユーザインタフェースをサポートすることを意図しています

• クリックは解析だけでなく，適切なコードも割り当てられる.

• Clickはコンテキスト概念を強く呼び出し，子命令が親命令からのデータに応答することを許す.

• Clickはすべてのパラメータやコマンドに強力な情報を提供するため，完全なCLIのための統一的なヘルプページを生成し，必要に応じてユーザが入力データを変換するのを助けることができる.

• Clickは何がタイプであるかをよく知っており，問題があれば，ユーザに一致したエラーメッセージを提供することができる.異なる開発者によって作成されたサブコマンドは突然死ぬことはなく、手動で処理されているため、異なるエラーメッセージを表示する。

• Clickはプログラム全体を時間とともに発展させるのに十分なメタ情報を持ち，開発者にプログラムを調整させることなくユーザ体験を改善することができる.たとえば，Clickがヘルプページのフォーマットを変更することを決定した場合，すべてのClickプログラムは自動的に利益を得る.

Clickの目標は，組合せ可能なシステムを構築することである.しかし，docoptは最も美しく，最も手作りのコマンドラインインタフェースの構築を目指している.この二つの目標は微妙な方法で衝突している。クリックは、人々が統一的なコマンドラインインタフェースを実現するために何らかのモードを実施することを能動的に阻止します。例えば、開発者として、ヘルプページ形式を設定する際にはほとんど選択されていません。

なぜハードコード行為をするのですか？

もう1つの問題は，Clickがoptparseを放棄し，構成可能なものを保持するのではなく，何らかのアクションをハードコード化することである.このような状況をもたらした原因は多面的だ。最大の問題は，構成可能性が多すぎて一致したコマンドライン体験を得ることが困難であることである.

一番いい例はoptparseです callback 任意の数のパラメータを受け取る機能.命令行は文法的に曖昧であるため，完全に可変なパラメータを実現することはできないいつもトレードオフをしなければなりません argparse このようなトレードオフはClickのようなシステムでさえ実現できないほど十分に重要だ。

このような特殊な場合，Clickはいくつかの公認例を用いて，うまく記録やテストが可能なコマンドラインインタフェースの構築を試みている.

なぜ自動校正がないのですか。

問題が来たが，optparseとargparseが自動拡張長パラメータをサポートしている以上，なぜClickはパラメータを自動修正しないのか.そうする理由は、これが後方互換性の負担だからだ。人間が自動的に修正されたパラメータに依存し始め，将来的に新たなパラメータが追加されると，スクリプトは作業を停止する可能性がある.このような問題は発見しにくいので、Clickはこのことで魔術になりたくない。

しかしながら、このような行為は、明示的なエイリアスなどのコンテンツをサポートするために、より高いレベルで実装されてもよい。より多くの情報については、参照されたい 命令別名 それがそうです。