Provide the full parsed config file to each plugin
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 20.6k
- フォーク
- 3.3k
- PR マージ指標
- PR 指標を取得中
説明
Feature
Provide the full parsed config file to each plugin
Pitch
Currently, Mypy plugins are passed only the Options object in their constructor, which captures Mypy options but not Mypy plugin options. Consequently, each plugins has to re-parse the file. This is a waste of time, may add to the necessary dependencies for a plugin with configuration, and requires re-implementing the logic for parsing different file types (TOML vs config). Here's an example of the pydantic plugin doing just this:
The neatest solution would be to pass the full config object to the constructor. Unfortunately, this would be a breaking change to the constructor signature, so probably the more palatable option would be to store the config options within each Plugin instance (in the constructor), which the subclasses can use if they want:
class SomeMypyPlugin(Plugin):
def __init__(self, options: Options) -> None:
super().__init__(options)
my_config_option = self.raw_config["tools"]["some_mypy_plugin"]
# use my_config_option
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
Plugin コンストラクターと設定読み込みパスから始め、次に issue にリンクされている pydantic plugin の例と比較します。現在 Options と plugin の設定がどのように解析されているかを追跡し、各 plugin が TOML または設定ファイルを再解析しなくても、解析済みの設定全体を plugin インスタンスから利用できる状態を完了と定義します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- tooling
- issue の種類
- 機能追加
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100