なぜクリックするのですか？ —ドキュメントをクリックします
なぜクリックするのですか？
コマンドラインユーティリティを作成するためのライブラリはたくさんあります。 Clickが存在するのはなぜですか？
この質問には簡単に答えることができます。Python用のコマンドラインユーティリティが1つもないため、次のボックスにチェックマークが付いています。
- 制限なしで怠惰に構成可能です
- Unix / POSIXコマンドライン規則の実装をサポートします
- 箱から出して環境変数から値をロードすることをサポートします
- カスタム値のプロンプトのサポート
- 完全にネスト可能で構成可能です
- Python2と3でも同じように機能します
- 箱から出してファイル処理をサポート
- 便利な一般的なヘルパーが付属しています（端末の寸法、ANSI色の取得、直接キーボード入力の取得、画面のクリア、構成パスの検索、アプリとエディターの起動など）
Clickには多くの選択肢があります。 明らかなものは、標準ライブラリのoptparseとargparseです。 他の何かがあなたに共鳴するかどうか見てみましょう。
Clickは実際に独自の引数の解析を実装し、optparseの解析動作に従ってoptparseまたはargparseを使用しません。 argparseに基づいていない理由は、argparseは設計によるコマンドの適切なネストを許可せず、POSIX準拠の引数処理に関していくつかの欠陥があるためです。
クリックは楽しくカスタマイズできるように設計されていますが、過度に柔軟ではありません。 たとえば、ヘルプページのカスタマイズ性には制約があります。 Clickは、複数のClickインスタンスが一緒につながれたときに意図したとおりに機能し続けることを約束しているため、この制約は意図的なものです。
カスタマイズ性が高すぎると、この約束が破られます。
Clickは、 Flask マイクロフレームワークエコシステムをサポートするために作成されました。これは、必要な機能を提供できるツールがないためです。
Clickとは何かを理解するには、複雑なアプリケーションの章を参照することを強くお勧めします。
なぜArgparseではないのですか？
クリックは、argparseではなくoptparseに内部的に基づいています。 これは、ユーザーが気にする必要のない実装の詳細です。 Clickは、任意のコマンドラインインターフェイスの処理を困難にする動作があるため、argparseに基づいていません。
- argparseには、何かが引数であるかオプションであるかを推測する動作が組み込まれています。 これは、不完全なコマンドラインを処理するときに問題になります。 コマンドラインの完全な知識がないと、動作は予測できなくなります。 これは、サブパーサーにディスパッチするというClickの野心に反します。
- argparseは、散在する引数の無効化をサポートしていません。 この機能がないと、Clickのネストされた解析を安全に実装することはできません。
Docoptなどはいかがですか？
Docoptやそのような多くのツールは、その動作が優れていますが、Clickのような方法でコマンドのネストや構成可能性を処理するツールはほとんどありません。 開発者の知る限り、Clickは、システム自体がサポートするレベルを超えるレベルのアプリケーションの構成可能性を作成することを目的とした最初のPythonライブラリです。
たとえば、Docoptは、ヘルプページを解析してから、それらのルールに従って解析することによって機能します。 これの副作用は、docoptがコマンドラインインターフェイスを処理する方法が非常に厳格であることです。 docoptの利点は、ヘルプページを強力に制御できることです。 欠点は、これが原因で、出力を現在の端末幅に再ラップできず、変換が困難になることです。 その上、docoptは基本的な解析に制限されています。 引数のディスパッチとコールバックの呼び出しまたは型は処理しません。 これは、解析結果を処理するための基本的なヘルプページに加えて、作成する必要のあるコードがたくさんあることを意味します。
しかし、何よりも、それは構成可能性を難しくします。 docoptはサブコマンドへのディスパッチをサポートしますが、たとえば、使用可能なものに基づく自動サブコマンド列挙を直接サポートしないか、サブコマンドが一貫した方法で機能するように強制しません。
これは問題ありませんが、Clickがどのように機能するかとは異なります。 Clickは、次の手順を実行することにより、完全に構成可能なコマンドラインユーザーインターフェイスをサポートすることを目的としています。
- Clickは解析するだけでなく、適切なコードにディスパッチします。
- Clickには、サブコマンドが親コマンドからのデータに応答できるようにする呼び出しコンテキストの強力な概念があります。
- Clickには、すべてのパラメーターとコマンドに関する強力な情報が用意されているため、完全なCLIの統合ヘルプページを生成し、ユーザーが必要に応じて入力データを変換するのを支援できます。
- Clickはタイプが何であるかをよく理解しており、問題が発生した場合にユーザーに一貫したエラーメッセージを表示できます。 別の開発者によって作成されたサブコマンドは、手動で処理されるため、別のエラーメッセージで突然終了することはありません。
- Clickには、プログラム全体で利用できる十分なメタ情報があり、開発者にプログラムの調整を強いることなく、時間の経過とともに進化し、ユーザーエクスペリエンスを向上させることができます。 たとえば、Clickがヘルプページのフォーマット方法を変更することを決定した場合、すべてのClickプログラムは自動的にこれから恩恵を受けます。
Clickの目的は、構成可能なシステムを作成することです。 一方、docoptの目的は、最も美しく手作りのコマンドラインインターフェイスを構築することです。 これらの2つの目標は、微妙な方法で互いに矛盾しています。 クリックは、統一されたコマンドラインインターフェイスを実現するために、人々が特定のパターンを実装することを積極的に防ぎます。 たとえば、開発者は、ヘルプページのフォーマットを選択することはほとんどできません。
なぜハードコードされた動作？
もう1つの質問は、Clickがoptparseから離れ、構成可能なままではなく、特定の動作をハードコードする理由です。 これには複数の理由があります。 最大の問題は、構成可能性が高すぎると、一貫したコマンドラインエクスペリエンスを実現するのが難しくなることです。
この最良の例は、任意の数の引数を受け入れるためのoptparseのcallback機能です。 コマンドラインの構文があいまいなため、完全可変引数を実装する方法はありません。 行う必要のあるトレードオフは常にあり、argparseの場合、これらのトレードオフは十分に重要であり、Clickのようなシステムをその上に実装することさえできません。
この特定のケースでは、Clickは、十分に文書化およびテストできるコマンドラインインターフェイスを構築するための、受け入れられているいくつかのパラダイムを維持しようとします。
なぜ自動修正がないのですか？
optparseとargparseでさえ長い引数の自動展開をサポートしているのに、Clickがパラメーターを自動修正しないのはなぜかという質問が出てきました。 これは、下位互換性に対する責任があるためです。 自動的に変更されたパラメータに依存し始め、将来誰かが新しいパラメータを追加した場合、スクリプトが機能しなくなる可能性があります。 これらの種類の問題を見つけるのは難しいので、Clickはこれについて魔法のようにしようとはしません。
ただし、この種の動作は、明示的なエイリアスなどをサポートするために、より高いレベルで実装できます。 詳細については、コマンドエイリアスを参照してください。
