なぜクリックするのですか？ —ドキュメントをクリックします

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

コマンドラインユーティリティを作成するためのライブラリはたくさんあります。 Clickが存在するのはなぜですか？

この質問には簡単に答えることができます。Python用のコマンドラインユーティリティが1つもないため、次のボックスにチェックマークが付いています。

• 制限なしで怠惰に構成可能です
• Unixコマンドラインの規則に完全に従います
• 箱から出して環境変数から値をロードすることをサポートします
• カスタム値のプロンプトのサポート
• 完全にネスト可能で構成可能です
• Python2と3でも同じように機能します
• 箱から出してファイル処理をサポート
• 便利な一般的なヘルパーが付属しています（端末の寸法、ANSI色の取得、直接キーボード入力の取得、画面のクリア、構成パスの検索、アプリとエディターの起動など）

クリックには多くの選択肢があり、もっと楽しんでいればそれらを見ることができます。 明らかなものは、標準ライブラリのoptparseとargparseです。

Clickは、実際にはoptparseのマイルドフォークのラッパーとして実装されており、それ自体の解析は実装していません。 argparseに基づいていない理由は、argparseは設計によるコマンドの適切なネストを許可せず、POSIX準拠の引数処理に関していくつかの欠陥があるためです。

Clickは、楽しく作業できるように設計されていると同時に、邪魔にならないように設計されています。 あまり柔軟性もありません。 たとえば、現在、ヘルプページをあまりカスタマイズすることはできません。 Clickはコマンドラインユーティリティをネストできるように設計されているため、これは意図的なものです。 2つのClickインスタンスを一緒にタックすることで、別のシステムと連携して動作するシステムを作成でき、それらは正常に動作し続けるという考え方です。

カスタマイズ性が高すぎると、この約束が破られます。

Clickは、 Flask マイクロフレームワークエコシステムをサポートするために作成されました。これは、必要な機能を提供できるツールがないためです。

Clickの概要を理解するには、複雑なアプリケーションの章を参照して、Clickが何に役立つかを確認することを強くお勧めします。

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

Clickは、内部的に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はこれについて魔法のようにしようとはしません。

ただし、この種の動作は、明示的なエイリアスなどをサポートするために、より高いレベルで実装できます。 詳細については、コマンドエイリアスを参照してください。