マージやコミットが行われなかった過去9か月間に、問題やプルリクエストが山積みになっているようです。
現在のメンテナである@Lokaltogが忙しいかもしれないことは理解できますが、メンテナンスの責任を分担または移管していただけませんか? おそらく、最もアクティブなフォークの@ PH111Pが喜んでいるかもしれません。
多くの人がこれを日常の生産性のために使用しており、アクティブなメンテナンスの欠如は少しフラストレーションです。
私は何年も電力線を使用していないので、興味がないことが私が電力線に貢献していない主な理由です。 誰かがそのタスクに取り組んでいる場合は、メインリポジトリに寄稿者を追加できれば幸いです。
喜んでお手伝いさせていただきます。
ありがとう。 @ ZyX-I何か考えはありますか?
私は興味がありますが、電力線の速度が遅いことに反対しているので、おそらく別の方向に物事を進めるでしょう。
編集: @Lokaltogが現在のメンテナと話し合ったり、彼らが何を見たいかについての声明を出したりするのは素晴らしいことです。 焦点が純粋に「更新が必要なため、各依存関係の新しいバージョンで電力線が壊れないようにする」場合、私は適度に興味がありますが、「電力線をより高速にし、より多くの人々が素晴らしい外観と素晴らしいものを持っていることを確認したいだけです。動作するシェル環境」、それなら間違いなく私が情熱を注いでいるものです。
@ryanerwinに同意します。 そして私も貢献することに興味があります。
@ryanerwin私は自分で電力線を使用しておらず、長年使用していないので、プロジェクトが現在どのような状態にあるのか
また、このリポジトリをどうするかわからないので、アーカイブして、別のイベントストリームの状況を回避するためにフォークを維持するためにコミュニティに任せることを検討しました。 しかし、これはおそらくリポジトリを殺してしまうので、代わりにあなたたちをメインタナーチームに追加し、しばらくの間開発をフォローアップしようとします。
ありがとう@Lokaltog!
今のところ、#1953や#2013などのいくつかのバグの修正を開始します。 将来的には、いくつかの新しい機能がありますが、メインリポジトリに追加することを検討する前に、それらを磨く必要があります。
私は約1。5年前にこのコードを調べましたが、その後どういうわけか興味を失いました。
Hacktoberfestで、私はここで何かをするように再びやる気になり、私のモチベーションが少し続くことを願っています。
とにかく、最近は少なくとももう少し活動があるように思えてうれしいです。
将来の方向性に関しては、現在のCI環境でいくつかの問題が発生しています。これにより、最大5,000行の出力が得られますが、そのほとんどは関連性のないbash出力のようであり、テストが失敗する理由とその方法は明確ではありません。正確に失敗しています。 誤解しないでください。このリポジトリには膨大な量のテストがあるという事実が気に入っていますが、テスト実行ワークフローをやり直すと読みやすさが向上する可能性があります。
また、私は現在のインストールと構成のワークフローの大ファンではありません。これらはすべて、面倒でエラーが発生しやすいようです。 なぜこれが起こるのか見当がつかないまま、電力線を構成するときにエラーが発生することがよくあります。 また、JSONはコメントをサポートしていないため、構成ファイルには非常に悪いと思います(VSCodeのようにコメントを追加しない場合)。
残念ながら、最後の点で、私はもっとうまくやる方法を尋ねるのは間違っていますが、それは将来取り組むべきことかもしれません。
@StopMotionCuber Json5はコメントをサポートしているため、プロジェクトがjson5で
別の構成を使用するように電力線を書き直す必要はないと思います(コメントは確かにいいでしょうが、おそらくそのためにアンダースコアで始まるフィールドを使用して、電力線によって無視される可能性があります):
powerline-lint
)にはリンターがあり、さらに、主要なテキストエディターは通常json
ファイルに直接エラーを表示しますテストに関しては、 @ StopMotionCuberに同意します。失敗したテストケースに移動するのは
価値があるのは、構成にYAMLを使用するように切り替えると、コメントのサポートが追加され、IMHOの構文がより読みやすくなります(重要なインデントに問題がない場合)。
YAMLはJSONのスーパーセットであるため、現在のすべての構成ファイルはすでに有効なYAMLであり、コードの変更は最小限に抑えられます。 おそらく、いくつかの追加のファイル拡張子を受け入れ、 yaml.safe_load
代わりにjson.load
yaml.safe_load
を使用するのと同じくらい簡単です。 PyYAML(または他のYAMLライブラリですが、PyYAMLが最も一般的です)への依存関係を追加する必要があります。
最も参考になるコメント
価値があるのは、構成にYAMLを使用するように切り替えると、コメントのサポートが追加され、IMHOの構文がより読みやすくなります(重要なインデントに問題がない場合)。
YAMLはJSONのスーパーセットであるため、現在のすべての構成ファイルはすでに有効なYAMLであり、コードの変更は最小限に抑えられます。 おそらく、いくつかの追加のファイル拡張子を受け入れ、
yaml.safe_load
代わりにjson.load
yaml.safe_load
を使用するのと同じくらい簡単です。 PyYAML(または他のYAMLライブラリですが、PyYAMLが最も一般的です)への依存関係を追加する必要があります。