SLURP

Great original post: SLURP

すでにコミュニティの多くの人々が SLURP の提案を見ていると思います。何人かの人たちに私の意見を聞かれたり、私が議論に参加しないことについて、まぁいろいろな意見をもらいました。この議題を私が避けてきた理由を今ここで書かせてください。作者はその提案をリリース前に教えてくれましたが、その時はサポートしないことを伝えました。私はまた、失礼にならないような形で SLURP へのコメントを控えていることも伝えました。残念ながら、その結果2つのことが起こりました。

  • 人によっては、とても良くない影響を与えてしまいました。
  • “fork” という用語の使い方の誤解、そして残念ながら作者はその間違いを訂正していません。

つまりまとめると: 提案は私のものではなく、変更を頼んだわけでも、誰かの頭に銃を向けているわけでもありません。この説明は間違っています。他に出すことができるコメントはいくらでもありますが、正直価値はないでしょう。

間違ってはいないことは、私は日常的に多くの人や Haskell のコミュニティやエコシステムマネジメントチームと直面している問題についてコミュニケーションを取っています。仕事で幅広いユーザーと交流し、不満を聞けばそれを誰かに伝えます。私も不満を持つことがあって、それを誰かに聞いてもらいます。この不満の中には、全てが同じようなものを指しているものもあります。

私が公開できる情報というのは限られています。なぜなら、私に寄せられるかなり多くのコメントが、公にされることを嫌うようなプライベートなメールで書かれているからです。そして経験上、私のことを嘘つきだと誹謗中傷する人たちがいることも分かっています。この絶え間ない誹謗中傷を理由に発言を避けてきましたが、私はここに残しておくべきだと決断しました。わかったのは次の2つのことです。

  • 私のやること成すこと全てが悪だと信じている人は、私が何か根拠を持っていてもそれを見ようとはしません。
  • 私が悪魔ではないという可能性を否定しない人は、もしかしたら私の声明をその通りに受け取ってくれるかもしれないということです。

以前の私は、アーキテクチャとエコシステム開発についてオープンに議論していました。これはオープンソースコミュニティを作る唯一無二の方法だと私は信じています。Stack 対 cabal の時代の緊張が最も高まったときに、多くの人がオープンな議論に異論を唱えたため、私はより静かなコミュニケーションのチャネルに移ることにしました。これはとても残念なことだったと感じています。私はエコシステムの計画についてもっとオープンに、声高に議論をしたいと思っています。他の人たちが簡単に情報にたどり着けるようにしたいと思っています。私は閉じた扉の裏側で全てを議論することを強く反対します。オープンな議論が再開できるかどうかはいずれわかることでしょう。

“fork” ってなに?

SLURP に関する議論の大部分が SLURP そのものとはなんの関係もないことは明らかですが、fork に関するコメントは関係があります。作者がドキュメントの中で fork という言葉を使うつもりだったのなら、まずは fork についてしっかりと説明することが望ましかったのではないでしょうか。これから Stackage と Stack の世界で使われている fork という言葉の意味について、私が知っていることをお話しようと思います。この話が本当に作者たちの意図を反映しているのかどうか、それは作者たちの発言を待って確認するしかありません。

ここでいう “fork” という用語は、「何かソフトウェアのプロジェクトを取ってきて、ソースコードを他の場所にホストして、別名で開発を続ける」といった文字通りの意味で使われているわけではありません (私の定義ですが)。この用語は、より一般的なものです。例えば、Stack はコードなんて何も共有していないのに、多くの人に cabal-install の fork だと言われています (もちろん、Cabal のようなベースとなるライブラリは共有していますが)。

誰もが固執していることについて、明確に言及しておきましょう。誰もが考えるような Hackage の直接の競争相手を作ろうとするやりとりには、全く関わっていません。私が知っている人で、こういうことをしたい人はいませんし、私もしたくありません。なぜなら、今日の Stackage と Stack は Hackage あってこそのものだからです。そして私の知人で、この構図を変えたい人は誰一人としていません。Hackage をコントロールしたいなどと考えている人はいないのです。

Hackage の “fork” というと、論理的にそういう結論に至るかもしれませんが、そうではないのです。

次に、この “fork” に関する具体的な頭痛のタネについてお話しましょう。

Hackage のリビジョン

多くの人が Hackage のリビジョンについて嫌悪感を示しています。私も Hackage リビジョンは嫌いです。そして、他の誰よりも嫌悪感を抱く理由を持っています。私は数週間から数ヶ月ほどの自分の人生を使って、いくつかのツールにリビジョンをサポートさせたことがあります。この凄惨な歴史を辿ることもできますが、プログラマの戦記になるだけで価値はないでしょう。それよりも今に向き合うことにします。

私はついに Stack 1.6 で、リビジョンの指定 (pinning) を完全にサポートしました。Stackage は既に長い間リビジョンの指定をサポートし続けています。Stackage にはいくつかのパッケージのリビジョンを無視しているものとしてリストアップする機能があります。

もし仮に、今聞かれたら私はリビジョンが悪いアイディアで、無効にすべきだと答えるでしょう。そして、依存関係の解決に関する問題について、より良い解決方法があると依然として答えるでしょう (これらについては、過去に長々と議論したことがあります)。同時に、そのコストは下がっています。ユーザーが extra-deps に特定のリビジョンを付けていないこと、そして Hackage におけるリビジョンのルールが緩すぎることについては実際、いまだに心配です。これについて懸念を抱いていることは確かですが、私の中の最優先事項ではありません。

ところが他の人は違う考えを持っているようです。私は Hackage Truestee が強制的に cabalファイルを編集することについて腹を立てている多くの人を知っています。彼らに反対することはありませんが、この話題に情熱を持っているわけでもありません。コミュニティのリーダーとの会話の中で、私はこの区別を明確に強調しました (少なくともそうしようとはしました)。

リビジョンに関する最大の懸念は、それの持つ社会的な影響です。すなわち、誰か別のものが自分のビルドの安定性を担うということです。これまでに何度も言及してきましたが、社会的緊張の原因の最たるものに、ビルドがいきなり止まったので上流の開発者に文句を言う、というものがあります。これは大惨事への第一歩で、PVP (Package Versioning Policy) + 依存解決という手法が持つ原理的な欠陥でした。そのため、固定ビルドプランに焦点を当てたツールが必要となるのです。私はこれを何年も主張してきましたが、結局は上流を説得することができなかったので Stack を大々的に作りました。

以上のことから、リビジョンとはフォークのような何かなのでしょうか? 違います。

キュレーション

数週間前、私はこんなツイートをしました。

Stackage のオリジナルデザインは、標準的な Linux ディストリビューションモデルに準拠していました。Hackage は私たちの上流でしたが、バージョンの境界が大きく壊れるのを防ぐために一連のパッチを整備し、あまりありませんでしたが時折 (たとえそうでも、正直覚えていませんが)、バグを修正するためにソースを編集したりしました。

2014年に Stackage を cabal と Haskell のプラットフォームに組み込む計画 (GPS Haskell のコードネームで開発していました。それが地面から飛び立つことは一度もありませんでしたが) について議論をしたとき、cabal, Hackage, そして Haskell Platform のメンテナに、ローカルの変更を Stackage が整備しないことを要求されました。なので私はその機能を削除したのですが、それは私たちが今までいた世界の話です。

この機能を復活させるかどうかは再検討中です。その理由を簡潔に説明しますと、これはフォークと捉えることができます。ソフトフォークと呼ぶ人もいるかもしれません。正直なところ、一連のパッチを整備するのは重労働なので Stackage に追加し直したい機能ではありません。しかし、多くのコミュニティがこの作業を必要としています。私がこのことを理解しているように、Nix も理解しています。もしもこれをフォークと言うのなら、私たちのエコシステムに広く浸透しているフォークなんでしょう。

このキュレーションで扱う理由としては、新しい依存バージョンへの更新が遅いパッケージを避けるため、というものがあります。Stackage のパッケージメンテナにとって、誰か他の人がその上限に満足しないからといって、自分のパッケージのバージョンを下げるのはかなりイライラするものがあるでしょう。キュレーションはこの辺の問題を何とかできるかもしれません。私はこれをおまけの特典のように考えていますが、必要なものではないです。

しかし、キュレーションには cabal-install 界隈では問題になっていないものの、Stackage や Stack 界隈で問題を引き起こしているパッケージをどうにかする、というもっと重要な理由があります。ここ数ヶ月の間に何回も問題が起こるまで、私は本当の問題だとは認識していませんでした。例えばこんな例があります

私はこの記事で、作者の誰かに何かを要求するつもりはありません。でも私は結局、これらの類の問題に多くの自分の時間を費やして対処してきています。これが現実です。私の友達や同僚は、緊急のリリースポイントを切ったり、様々な持ち越し作業に巻き込まれています。Cabal のライブラリの仕様に明記されているべきだが文書化されていないような何かのために、多くの時間を割いて Stack を変更しなければならないような現状に私の人生を浪費したくはありません。

Hackage は cabal-install を壊さないために、既に大きな苦労をしています。多くの人が、 ^>= 演算子の導入がどのように Stack 1.5 を破壊したか聞いたことがあるのではないでしょうか。しかし、実はこの演算子の導入は cabal-install 1.24 も壊していたのです。この事実を知っている人がいないのは、Hackage がこれらのファイルを古いバージョンの cabal-install から隠すような措置を導入したからです。このキュレーションのアイディアは Stack の破壊に対応する術を Stackage に対して提供するものです。Hackage も同じ方法で cabal-install へのダメージに対処するでしょう。

そして、私は同じ類の処置を、Hackage から Stack へしてもらえないかとお願いしました。このお願いは、優先的な処置を求める声に後押しされています。この記事の読者は、各々の判断で自分がどう感じるか考えてください。

まとめると: 私は Stackage に上流のパッケージのパッチを当てられるようにしようとしています。他の人はフォークという言葉を使うかもしれませんが、私はこれをフォークではなくキュレーションだと考えています。

Hackage へのアップロードを避ける

まず、これは私の好みですが、私のパッケージは Hackage に上げ続けたいと考えています。conduit や yesod, その他鋭意 Hackage でメンテ中の 80 を超えるパッケージの更新をやめるつもりも、そうしたいという願望もありません。そうは言っても、全員が全員同じように感じているわけではありません。

現在 Stackage は Hackage の下流になっています。最初にパッケージが Hackage にアップロードされない限り、そのパッケージを Stackage に入れることはできません。しかし、この状況は終わりを告げようとしています。およそ、現状を変えようとしているグループは以下の 3 パターンに分けられるでしょう。

  1. 少なくとも一部の PVP 支持者は、PVP に従わないパッケージ作成者に対して、そのパッケージを Hackage にアップロードしないように要請 (要求) しています。これは私が幾度となく指摘してきたように、Hackage 公式のガイドラインと完全に矛盾しているにも関わらず、彼らはしつこく同じ趣旨の発言を続けています。
  2. PVP に反対する人の中には、基本的に (1) の理由で、Hackage にアップロードしたくない、という人もいます。PVP の遵守という観点で、たくさんの張りつめた議論がありました。これを避けるための最も簡単な方法は Hackage にアップロードしない、というものでした。私はこういった事情があって Hackage や Stackage にコードをリリースしない人たちを知っています。しぶしぶこうしている人もいますが、その全員が同じ理由で Hackage を避けたがっています。
  3. 技術的に見て、中央リポジトリに手作業で tarball をアップロードするようなモデルは、時代遅れになってきていると感じる人もいます。そういった人たちは、タグやリリースブランチを使って自動化された、Git ベースのリリースに基づいたワークフローを考えています。これによる社会的な影響は何もなく、どちらかと言うと Hackage が現在サポートしていない、技術的に違うものを探してみたいという願望です。
  1. 番目の状況は、私の大きな頭痛の種でした。私は Hackage Trustee のガイドラインと Hackage のルールを変更して、彼らの言動 (Hackage にアップロードしないように私的なメールで要求したり、個人や企業に対して PVP に従っていないことを公に批判したり) について明確に禁止するように要望を出していました。実際、私が思うに、この要望は究極的には SLURP に結びつくものです。私は変更しなければフォークするぞと脅したりしたでしょうか? あー、そう思いたいならそれでもいいでしょう。私は Hackage を使うのをやめようと言い続けてきました。完全にです。私はこのような Hackage の使い方が許可されるように、公式のポリシーに対して変更を求めました。

現状を見たらわかりますが、Hackage のポリシーにそんな変更はされませんでした。私は (2) と (3) のグループに対して何を思うのか、言及していませんでしたね。しかし (3) の主張からもわかるように、Hackage とは別の代替パッケージリポジトリをホストしたりするのは全くもって意味がありません。なので、私はまたここで保証します。最も文字通りの Hackage の fork は、私も私が話しかけているあなたも誰も望んでいないものになるでしょう。

また他の選択肢は Stackage に Hackage に加え、Git リポジトリから直接パッケージをプルできるようにする、というものです。これは先に挙げた 問題 (1) に対するワークアラウンドとして議論されています。あることを主張して、一度離れてもう一度それを主張するようになる… なんてことはありません。私はむしろ、Hackage が全員からパッケージのアップロードを受け付けることを明確にすることを望んでいますし、それと比べれば Stackage を別のソースに対して解放するような要求は少なくなります (3 番目のグループは純粋に技術的な観点から実験したいと思っているようですが)。

私は銃で誰かの頭を狙っているでしょうか? それはあなたが決めることです。これが私が知る限りの本当の物語です。

まとめると、これは潜在的な fork に最も近いもので、Git リポジトリが Hackage の代替のソースとして許可されたらこうなります。

まとめ

私は上記の問題を解決するための努力をするにあたって、複数の人と長く非公開な議論をしてきました。先ほども話したように、私はいつも公の場で行われる議論が好きです。SLURP の提案がどうなったかを鑑み、私はやはり公の議論はより良いという立場を取ろうと思います。“fork” という言葉を使って、とても多くの人を怖がらせてしまったことは申し訳なく思っています。本当に怖がっていた人に対して、私は鬼のようなことをしてしまっていたようです。説明に 2 日間待たせてしまい、申し訳ありませんでした。