lestrrat

@soh335 PoC で schemalintを書いてみました。＞ https://github.com/schemalex/schemalex/tree/topic/schemalint

Bは何よりもコードがごちゃごちゃするのが嫌ですねー。ツールの名前はまぁポリシーの問題なんでどちらでも、って感じです。

2ヶ月に一回くらいschemalintが欲しくなるのですが、またその時期がやってきました。 僕はあの後何回か考え直しましたが、やはりコマンド群を新設するのを推します。 大きな理由は上に書いた通り、特に名前の点ですが、あといくつか追加を書いておきます ## サブコマンド型にした場合APIが変わる これまで `schemalex [options...]` だったのが `schemalex subcommand [options...]`になるので、ユーザの対応が必要。コマンドを新設した場合は、単純にschemalexを、後方互換なバイナリのエイリアスなりなんなりにしておけばよい。 ## 現時点で、schemalex全体のビジョンがない 例えば、`gcloud`コマンドは「Google Cloud Platformにおける全てを管理する」ツールなので、`gcloud [subcommand] ...`は理解できますし、そこに入るサブコマンドもオプション等の命名パターンや、共通コードが比較的明確です。`git`も「gitに関する全てを管理する」ツールなので同様です。 ではschemalexは？現在のところschemalexは「パース」「diff」しかしないツールであり、「lint」と「deploy」を追加する可能性がある程度。で、もしこれをひとつのなまえのもとに統合するなら、これは一体なんのツールなんだろう？ スキーマ管理全て？だったらやっぱりそもそもschemalexがおかしい気がします。スキーマデプロイ？でもするとlintはここに入るべきなのか…？ ↑はとりあえず僕の中で命名・グルーピング的に納得のいかない部分を書き出しましたが、もちろん同じ数だけ反対の方向性も出てくる気がします。ではそこで方向性を示してもらえるのか？がポイントな気がします。今の僕の感覚では多分そこまで考えている人はいない、と思うのですよね。 「それを今すぐ考えるべきだ！」というわけではないです。しかし、この状態で僕とかがもう少し機能を足していきたいと思った場合にschemalexコマンドを大統一プラットフォームにするのは危険だと思うのです。バラバラの命名規則や、入っているべきではない機能が入り始めた時に、大統一プラットフォームでは簡単には直せません。でもバラバラのコマンドがたくさんでてきて困った結果、キレイにデザインしなおした上でひとつのバイナリのラッパに戻すのは比較的簡単なのでは？と思います。

Just thinking out loud here: 1. All statements should actually be contained in a "context" DB structure 2. Then we know wha the targets are for the statements 3. If...

@gfx "Sure. I will change the level of two warning types as:" Has it been changed?

@gfx Has this been fixed?

things around the iterators (jwk.HeaderPair/HeaderVisitor/HeaderVisitorFunc) need a good hard rethink

If the project owners give me the "Go!" signal, I certainly would go ahead and change this.

@simonswine Hmm, I don't follow. I thought the original purpose was to make the error (of not setting the proper Host header) more explicit? So if the upstream sent us...

@simonswine K, one last thing: whose instance ID are we talking about? kube-lego.Deployment.uid ? kube-lego.Pod.uid? or something else?