Pythonファイルを構成ファイルとして使用するのはどれほど悪い考えですか？

アプリケーションの構成には常にJSONファイルを使用しています。私は多くのJavaをコーディングしたときからそれらを使い始めましたが、現在は主にサーバーサイドとデータサイエンスのPython開発に取り組んでおり、JSONがこれ以上正しい方法であるかどうかはわかりません。

Celeryが実際のPythonファイルを構成に使用するのを見てきました。当初、私はそれについて懐疑的でした。しかし、構成に単純なPythonデータ構造を使用するという考えは、私に成長し始めています。いくつかの長所：

• データ構造は、通常コーディングしているものと同じです。そのため、心のフレームを変更する必要はありません。
• 私のIDE（PyCharm）は、構成とコードの関係を理解し​​ています。Ctrl+ Bを使用すると、構成とコードを簡単に切り替えることができます。
• IMOの不要な厳密なJSONを使用する必要はありません。二重引用符、末尾のコンマ、コメントはありません。
• 作業中のアプリケーションでテスト構成を作成し、変換やJSON解析を行わずに簡単に構成ファイルに移植できます。
• 本当に必要な場合は、構成ファイルで非常に簡単なスクリプトを実行することができます。（これは非常に制限されるべきですが。）

だから、私の質問は次のとおりです。切り替えた場合、どのように自分の足を撃ちますか？

熟練していないエンドユーザーが構成ファイルを使用することはありません。構成ファイルへの変更はすべてGitに現在コミットされており、継続的な展開の一部としてサーバーにロールアウトされています。緊急事態があるか、開発中でない限り、手動で構成を変更することはありません。

（私はYAMLを検討しましたが、それについて何かが私をいらいらさせます。それで、今のところ、それはアメリカのテーブルから外れています。）

構成ファイルの代わりにスクリプト言語を使用することは、一見すると素晴らしいように見えます。あなたはその言語のフルパワーを利用でき、簡単にeval()またはimportそれを実行できます。実際には、いくつかの落とし穴があります。

• これはプログラミング言語であり、学習する必要があります。設定を編集するには、この言語を十分に理解する必要があります。通常、構成ファイルの形式はより単純であり、間違えにくいです。

• これはプログラミング言語です。つまり、構成のデバッグが難しくなる可能性があります。通常の設定ファイルでは、それを見て、各プロパティにどの値が提供されるかを確認します。スクリプトを使用する場合、値を確認するには最初にスクリプトを実行する必要があります。

• プログラミング言語であるため、構成と実際のプログラムを明確に分離することは困難です。この種の拡張性が必要な場合もありますが、その時点で実際のプラグインシステムを探している可能性があります。

• それはプログラミング言語です。つまり、コンフィグはプログラミング言語ができることなら何でもできるということです。したがって、言語の柔軟性の多くを無効にするサンドボックスソリューションを使用しているか、構成作成者に高い信頼を置いています。

そのため、ツールの対象ユーザーが開発者（Sphinx configまたはPythonプロジェクトのsetup.pyなど）の場合、構成にスクリプトを使用しても大丈夫です。実行可能な構成を持つ他のプログラムは、Bashのようなシェル、およびVimのようなエディターです。

構成に多くの条件付きセクションが含まれている場合、またはコールバック/プラグインを提供する場合は、構成にプログラミング言語を使用する必要があります。eval（）の代わりにスクリプトを直接使用すると、いくつかの設定フィールドをよりデバッグしやすくなります（スタックトレースと行番号を考えてください！）。

プログラミング言語を直接使用することも、構成が非常に繰り返されるため、構成を自動生成するスクリプトを作成している場合に有効です。しかし、おそらく構成のより良いデータモデルは、そのような明示的な構成の必要性を取り除くことができますか？たとえば、構成ファイルに、後で展開するプレースホルダーを含めることができれば便利です。ときどき見られる別の機能は、互いに優先順位が異なる複数の構成ファイルです。ただし、それ自体にいくつかの問題が生じます。

ほとんどの場合、INIファイル、Javaプロパティファイル、またはYAMLドキュメントは、構成により適しています。複雑なデータモデルの場合、XMLも適用可能です。お気付きのとおり、JSONには人間が編集可能な構成ファイルとしては不適切な側面がいくつかありますが、それは優れたデータ交換形式です。

アモンの答えのすべてに+1 。これを追加したいと思います。

異なる言語で記述されたコード内から同じ構成を初めてインポートする場合は、Pythonコードを構成言語として使用することを後悔します。たとえば、プロジェクトの一部であり、C ++やRubyなどで記述されたコードが構成をプルする必要がある場合、Pythonインタープリターをライブラリとしてリンクするか、Pythonコプロセスで構成を解析する必要があります。扱いにくい、難しい、またはオーバーヘッドが大きい。

現在、この構成をインポートするコードはすべてPythonで記述されている可能性があり、明日も同様であると思われるかもしれませんが、確かに知っていますか？

あなたはあなたの設定でロジック（静的データ構造以外のもの）を少しでも使用するだろうと言いましたが、それは良いことですが、それが少しでもあれば、それを元に戻すのは難しいでしょう宣言的な構成ファイルに戻ることができます。

レコードの編集：プロジェクトが別の言語で完全に完全に書き直される可能性がどれほどありそうであるか、またはありそうにないかについて、この回答について複数の人々がコメントしています。完全な後方互換性のある書き換えはおそらくほとんど見られないと言っても過言ではありません。私が実際に念頭に置いていたのは、同じプロジェクト（および同じ構成にアクセスする必要がある）の断片が異なる言語で書かれていることでした。たとえば、速度を上げるためにC ++でスタックを提供し、Pythonでバッチデータベースをクリーンアップし、いくつかのシェルスクリプトを接着剤として使用します。だから、そのケースについても考えてください:)

他の答えはすでに非常に良いです、私はいくつかのプロジェクトで実際の使用法の経験をもたらすだけです。

長所

それらはほとんどがすでに綴られています：

• Pythonプログラムを使用している場合、解析は簡単です（eval）。それは（私たちのプログラムでは、我々は/ダンプを通じてうまくロードされている幾何学的な点や変換、持っていても、より複雑なデータ型のために自動的に動作repr/をeval）;
• ほんの数行のコードで「偽の設定」を作成するのは簡単です。
• JSONよりも構造が優れており、IMOの方が構文が優れています（コメントがあり、辞書キーを二重引用符で囲む必要がない場合でも、読みやすくなります）。

短所

• 悪意のあるユーザーは、メインプログラムが実行できることをすべて実行できます。一般に、ユーザーが構成ファイルを変更できる場合、ユーザーはアプリケーションでできることは何でもできるので、私はこれほど問題を考えません。
• Pythonプログラムにもう参加していない場合は、問題が発生しています。構成ファイルのいくつかは元のアプリケーションにプライベートのままでしたが、特にいくつかの異なるプログラムで使用される情報を保存するようになりました。そのほとんどは現在C ++にあります。 Pythonのサブセットrepr。これは明らかに悪いことです。
• プログラムがPythonのままであっても、Pythonバージョンを変更できます。アプリケーションがPython 2で起動したとしましょう。多くのテストを行った後、Python 3に移行できました-残念ながら、実際にはすべてのコードをテストしていません -Python 2用に作成されたすべての構成ファイルが顧客のマシン上にあり、本当にコントロールできません。Python 2インタープリターをバンドル/コールしない限り、古い構成ファイルを読み取るための「互換性モード」を提供することさえできません（ファイル形式でよく行われます）。

• Pythonを使用している場合でも、コードから構成ファイルを変更することは実際の問題です。なぜなら、コードを変更することは決して簡単ではないからです。特に、リッチな構文を持ち、LISPなどにないコードです。私たちの一つのプログラムでは、（特定の設定があるもののリストですもともと手で書かれたPythonで設定ファイルを、持っていますが、後でソフトウェア経由で操作することが有用である判明どの方法 GUIを使用して並べ替えが簡単）。次の理由により、これは大きな問題です。

  • parse→AST→rewriteラウンドトリップを実行するだけでも簡単ではありません（提案されたソリューションの半分は後に「廃止、使用しない、すべての場合に機能しない」とマークされていることに気付くでしょう）。
  • たとえ彼らが働いたとしても、ASTはあまりにも低レベルです。一般に、ファイルに実行された計算の結果を操作することに興味があります。ファイルにもたらされたステップではありません。
  • 興味のある値を単に編集することはできないという単純な事実に至ります。なぜなら、これらの値は、コードでは理解/操作できない複雑な計算によって生成される可能性があるからです。

  これをJSON、INI、または（God forbid！）XMLと比較してください。XMLでは、データの損失なしに常にメモリ内表現を編集および書き戻すことができます（XML、ほとんどのDOMパーサーはテキストノードおよびコメントノードに空白を保持できます）。少なくとも一部のフォーマットのみを失います（JSON、フォーマット自体では、読み取っている生データ以外は許可されません）。

したがって、いつものように、明確な解決策はありません。この問題に関する私の現在のポリシーは次のとおりです。

• 構成ファイルが次の場合：

  • 確かにPythonアプリケーションのために、そしてそれに対してプライベートです-のように、誰もそれから読み込もうとしません。
  • 手書き;
  • 信頼できるソースからのもの。
  • ターゲットアプリケーションのデータ型を使用することは本当に重要です。

  Pythonファイルは有効なアイデアかもしれません。

• 代わりに：

  • 他のアプリケーションから読み取られる可能性があります。
  • このファイルは、アプリケーションによって編集される可能性があり、場合によっては私のアプリケーション自体も編集される可能性があります。
  • 信頼できないソースから提供されます。

  「データのみ」の形式の方が良いかもしれません。

単一の選択を行う必要はないことに注意してください。最近、両方のアプローチを使用するアプリケーションを作成しました。私は、Pythonの素晴らしいボーナスを得る利点がある最初のセットアップ、手書きの設定、およびUIから編集された構成用のJSONファイルを持つ、ほとんど変更されていないファイルを持っています。

主な質問は次のとおりです。設定ファイルをチューリング完全言語（Pythonなど）にしたいですか？それが必要な場合は、GuileやLuaなどの他の（チューリング完了）スクリプト言語を埋め込むことも検討してください（Pythonよりも「使用」または「埋め込み」が簡単であると認識される可能性があるため、Extending＆の章を読んでください）Pythonの埋め込み）。（-Eg他の回答ので、私はそれをさらに議論しないでしょうアモンによっては -深さという議論）が、ことがわかり、アプリケーション内のスクリプト言語を埋め込むことで、主要な建築の選択はあなたが非常に考慮しなければならないことを、早期に; 後でその選択をすることは本当にお勧めしません！

「スクリプト」を介して構成可能なプログラムのよく知られた例は、GNU emacsエディター（またはおそらく独自の領域ではAutoCAD）です。したがって、スクリプトを受け入れると、一部のユーザーは最終的にその機能を広範囲に使用し、おそらく乱用することになり、数千行のスクリプトを作成することに注意してください。したがって、十分に優れたスクリプト言語を選択することが重要です。

ただし、（少なくともPOSIXシステムでは）初期化時に構成「ファイル」を動的に計算できるようにすると便利かもしれません（もちろん、システム管理者またはユーザーに健全な構成の負担を任せます。実際は構成です）ファイルまたはコマンドからのテキスト）。そのためには、単純に採用可能性条約を（および文書化、それを）設定ファイルのパスは、例えば、Aで始まること!や|、実際にシェルでコマンドを使用すると、と読んでいましたパイプライン。これにより、ユーザーは、最も使い慣れている「プリプロセッサ」または「スクリプト言語」を使用する選択ができます。

^{（動的に計算された構成を受け入れる場合、セキュリティの問題についてユーザーを信頼する必要があります）}

したがって、初期化コードでは、main（たとえば）いくつかの--config 引数 confargを受け入れてFILE*configf;、そこから引数を取得します。その引数が!（(confarg[0]=='!')...の場合）で始まる場合、configf = popen(confarg+1, "r");そのパイプを使用して閉じpclose(configf);ます。それ以外の場合はconfigf=fopen(confarg, "r");、そのファイルを使用して閉じますfclose(configf);（エラーチェックを忘れないでください）。pipe（7）、popen（3）、fopen（3）を参照してください。Pythonでコーディングされたアプリケーションについては、os.popenなどについて読んでください。

^{（上記のトリックをバイパスする!foo.configために渡すという名前の構成ファイルを渡したい奇妙なユーザー向けのドキュメント）./!foo.configpopen}

ところで、このようなトリックは利便性にすぎません（上級ユーザーが構成ファイルを生成するためにシェルスクリプトをコーディングするなどを必要としないようにするため）。ユーザーがバグを報告する場合は、生成された構成ファイルを送信する必要があります...

また、たとえばdlopen（3）を使用して、初期化時にプラグインを使用およびロードする機能を使用してアプリケーションを設計できることにも注意してください（そのプラグインについてユーザーを信頼する必要があります）。繰り返しになりますが、これは非常に重要なアーキテクチャ上の決定です（これらのプラグインとアプリケーションに関するある程度安定したAPIと規則を定義して提供する必要があります）。

Pythonのようなスクリプト言語でコーディングされたアプリケーションの場合、evalまたはexecまたは同様のプリミティブのプログラム引数を受け入れることもできます。繰り返しますが、セキュリティの問題は（上級）ユーザーの関心事です。

構成ファイルのテキスト形式（生成されたかどうかに関係なく）については、ほとんどの場合それを適切に文書化する必要があると思います（そして、特定の形式の選択はそれほど重要ではありませんが、ユーザーがその中のいくつかの-スキップされたコメント）。JSON（できれば、//eolまたは/*... */... までの通常のコメントを受け入れてスキップするJSONパーサーで）、YAML、XML、INI、または独自のものを使用できます。構成ファイルの解析はかなり簡単です（そのタスクに関連する多くのライブラリがあります）。

amonの答えに加えて、代替案を検討しましたか？JSONはおそらくあなたが必要とする以上のものですが、Pythonファイルはおそらく上記の理由で将来問題を起こすでしょう。

ただし、Pythonにはすでに、すべてのニーズを満たすことができる非常に単純な構成言語用の構成パーサーがあります。ConfigParserモジュールは、簡単な設定言語を実装しています。

TCLで記述された構成ファイルを持ついくつかの有名なソフトウェアで長い間働いてきたので、アイデアは新しいものではありません。言語を知らないユーザーでも、単一のset name valueステートメントを使用して簡単な構成ファイルを作成/編集できる一方で、より高度なユーザーや開発者はこれで高度なトリックを引き出すことができるため、これは非常にうまくいきました。

「構成ファイルをデバッグするのが難しくなる可能性がある」ことは、有効な懸念事項ではないと思います。アプリケーションがユーザーにスクリプトの作成を強制しない限り、ユーザーは常に設定ファイルで単純な割り当てを使用できます。これは、JSONやXMLに比べて簡単に取得することはほとんどありません。

構成の書き換えは問題ですが、見た目ほど悪くはありません。任意のコードを更新することは不可能ですが、ファイルから設定をロードし、変更して保存し直すことはできます。基本的に、読み取り専用ではない設定ファイルでスクリプトを作成する場合、保存されると同等のset name valueステートメントのリストになります。これが起こる良いヒントは、ファイルの先頭にある「編集しない」コメントです。

考慮すべきことの1つは、などの単純な正規表現ベースのツールでは構成ファイルを確実に読み取れないことですがsed、私が理解している限り、これは既に現在のJSONファイルには当てはまらないため、失うものはほとんどありません。

構成ファイルを実行するときは、適切なサンドボックス手法を使用してください。

ここでの他の良い答えのすべての有効なポイント（うわー、彼らはチューリング完全な概念についても言及しました）に加えて、Pythonファイルで作業している場合でも、Pythonファイルを構成として使用しないいくつかの堅実な実用的な理由が実際にありますプロジェクトのみ。

1. Pythonソースファイル内の設定は、技術的には読み取り専用のデータファイルではなく、実行可能なソースコードの一部です。あなたがこのルートに行けば、あなたは通常そうするでしょうimport config。なぜなら、その種の「便利さ」は、おそらく最初にPythonファイルを設定として使用することから始めた主な理由の1つだからです。そのconfig.pyをリポジトリにコミットする傾向があります。そうしないと、エンドユーザーがプログラムを初めて実行しようとしたときに、わかりにくいImportErrorが発生します。

2. そのconfig.pyをリポジトリに実際にコミットすると、チームメンバーは異なる環境で異なる設定を持つことになります。いつか何らかのメンバーが誤って自分のローカル設定ファイルをレポジトリにコミットすることを想像してください。

3. 最後になりますが、プロジェクトの構成ファイルにパスワードを含めることができます。（これはそれ自体が議論の余地のある慣習ですが、とにかく起こります。）そして、設定ファイルがレポジトリに存在する場合、クレデンシャルをパブリックレポジトリにコミットするリスクがあります。

現在、ユニバーサルJSON形式などのデータのみの構成ファイルを使用すると、上記の3つの問題をすべて回避できます。これは、ユーザーに独自のconfig.jsonを作成してプログラムにフィードするよう合理的に依頼できるためです。

PS：JSONには多くの制限があることは事実です。OPが言及している2つの制限は、創造性によって解決できます。

• JSONファイルにコメントを入れる方法（適切）

• そして、通常、末尾のコンマルールをバイパスするプレースホルダーがあります。このような：

  {
      "foo": 123,
      "bar": 456,
      "_placeholder_": "all other lines in this file can now contain trailing comma"
  }