ビルドシステムのPantsが、現在はアーリーアダプタ向けに提供されている次期リリースにおいて、これまでサポートしていたPythonに加えて、Java、Scala、Goをサポートするようになる。
Pantsは高速でスケーラブル、ユーザフレンドリなビルドシステムを目指している。そのために、ビルドを同時実行可能な多数の小さなタスクに分割し、それらの結果をキャッシュすることにより、確実に必要なもの以外は再実行しないようにしている。Bazelなども利用するキャッシュおよびリモート実行用のAPIに準拠するサーバであれば、Pantsを実行することができる。このような構成により、同じように設定された複数のホスト間で作業を分割するのにも適している。
Pantsの目標のひとつは、不必要なコンフィギュレーションを避けることにより、ビルドファイルの乱雑さを低下させて、開発者の負担を軽減することにある。実際Pantsでは多数のデフォルト選択が用意されているので、ほとんどのプロジェクトでは、使用したいPantsのバージョンと必要なバックエンドをpants.toml設定ファイルに定義するだけでよい。これにより、検索するソースファイルと適切なBUILDファイルをPantsに指示することができる。以下の例では、Python用のバックエンドのリストを、リンティング(linting)とmypyのサポートを含めて指定している。
[GLOBAL]
pants_version = "2.8.0"
backend_packages.add = [
"pants.backend.python",
"pants.backend.python.lint.docformatter",
"pants.backend.python.lint.black",
"pants.backend.python.lint.flake8",
"pants.backend.python.lint.isort",
"pants.backend.python.typecheck.mypy",
]
各バックエンドは、それぞれの.tomlセクションに独自のオプションを指定することで設定が可能である。ライブラリや実行ファイルの生成に加えて、対応するバックエンドを使うことで、DockerやAWS Lambdaへのデプロイを行うこともできる。
Pantsの大部分はPythonで記述されているが、クライアントのレイテンシ低減のためにRustへのマイグレーションが進められている。また、プラグイン開発用のAPIも提供されており、必要に応じてカスタムビルドステップを追加することも可能だ。
開発者のひとりであるBenjy Weinberger氏と、メインスポンサのToolchainで現在CEOを務めるJohn Sirois氏に話を聞いた。
InfoQ: ビルドシステムの分野には、すでにたくさんのプロダクトが存在します。その中で、新たなビルドシステムにニーズがあると思った理由は何でしょう？他のソリューションと比較した時、Pantsがユニークな点は何ですか？
Benjy Weinberger: 過去5～10年間、コードベースとそのビルドワークフローは複雑化の一途をたどっています。収束する気配はほとんど見られません。理由はいろいろあります。サードパーティ製のプロダクトへの依存関係の複雑化、アプリケーションフレームワークや抽象化レイヤの増加、新たなデプロイメントパラダイム(コンテナ、クラウド関数、マイクロサービス)の登場、ひとつの工学分野としてのデータサイエンスの出現、などが挙げられるでしょう。
既存のツールは、このようなトレンドを考慮して設計されていません。これらを含むイノベーションを前にした時、機能やスケーラビリティの面で制約を受けることが少なくないのです。既存のツールは、A) ひとつの言語、ひとつのフレームワークを使用した小～中規模のコードベースのサポート、あるいは B) ひとつの企業の内部ニーズのサポート、といった理由で設計されたものがほとんどです。どちらであっても、そのようなツールでは、今日のエンジニアリングチームの大部分が抱えているニーズには対処できません。
Pants v2は、これらのユースケースを念頭に設計されました。特に、さまざまな産業にわたって、規模もまちまちなエンジニアリングチームがどのように使用するのか、ということを考慮しています。Pantsは、前世代のビルドシステムではニーズを満たすことのできない多くのユーザにとって、ユーザビリティ、安定性、パフォーマンスの面で大きな飛躍を遂げたものになっています。
Pantsのもうひとつの重要なイノベーションは人間工学にあります — 前世代のビルドシステムの中でも、特に複数言語対応のものには、学習曲線が急勾配になる傾向があります。何をする場合においても、ユーザに対して、新たな用語分野の取り込みを求めているからです。Pantsは、それが可能なすべての場面において、ユーザが使い慣れている言語やフレームワークの自然なイディオムで動作します。
技術的な機能以外でPantsを際立たせているのは、非常に力強いそのオープンソースコミュニティ精神です。設計と実装においては、すべての個人や企業が参加者として対等です。これによって多様なユーザのニーズに応えることができています。設計や優先順位設定に対しては、コミュニティのフィードバックを積極的に求めています。さらにコミュニティは、Pantsを導入して使用するためのフレンドリなリソースでもあります。
InfoQ: ご自身の見解として、Pantsの一般的な競合相手は何だと思いますか？
Weinvberger: 市場における最大の"競合相手"は特定のシステムというよりも、むしろ寄せ集めの、アドホックなDIYスクリプトの方です。これらに対する不満は高いのですが、自分たちでそれを改善するために必要な専門知識や経験を持っているチームはほとんどありません。Pantsはこのビルド作業をすべてシステム化して、統一的で人間工学的な、ユースケースに最もフィットするユーザエクスペリエンスを提供します。目の前のタスクから注意をそらすことなく、キャッシュや同時実行によってパフォーマンスの向上を実現しています。自家製のソリューションはスケールアップできないため、人為的なコードベースの分割が行われることが少なくありませんが、この方法はリポジトリ境界を越えてコードをコンシュームするための余分なステップが必要になるので、結果的に共同開発をスローダウンさせる原因になります。Pantsはコードベースの統合性を維持することによって、迅速なイテレーションと軽快な開発をサポートします。
それ以外では、もちろん、Bazelが当然の競合相手だと考えています。ここで注目してほしいのは、BazelはGoogleの社内使用のために設計されたものだ、ということです。その非公式なスローガンは、"Googleのようにビルドする"というものなのです。でも、あなたはGoogleではありませんから、Googleのようにビルドしたいとは思わないはずです！あなたのユースケースはまったく違うでしょう。Bazelはそのために設計されてはいません。例えば、Googleではサードパーティの依存関係を使用していないので、その部分のBazelのサポートは場当たり的で、Pantsの堅牢さとは対照的です。Pantsはまた、導入や使用、カスタマイズの点でもはるかに簡単です。エンジニアリングチームがBazelよりもPantsを選択するべき理由は他にもあって、この記事に要約されています。
InfoQ: Pants 2.8では、サポート対象の言語が大幅に拡張されました。来年のロードマップについて教えて頂けますか？
Weinberger: ロードマップはコミュニティ主導なので、2022年の計画はまだ検討中です！私たちはユーザの意見を取り入れて成長していて、数か月先の計画を立てているので、今がそれを提供する絶好の機会です。とは言っても、いくつかのテーマはあります。
セキュリティ: サプライチェーンなどの攻撃に対して、ビルドをロックダウンするための、Pantsの機能改善。この領域ではすでに充実したサポートがありますが、セキュリティを取り巻く状況は常に進化しているので、常に警戒が必要です。
すべての企業ユーザに優れたビルドエクスペリエンスを提供するための、スケーラビリティやパフォーマンスのさらなる向上。
新たな言語のサポート: どの言語になるのかはコミュニティのフィードバック次第ですが、JavaScript/TypeScriptやRustが候補です。
IDE — 具体的にはIntelliJ/PyCharmとVS Codeとのインテグレーション。
Pantsはオープンソースで、コミュニティはSlack上で活発に活動している。前述のように最新バージョンは、関心のある開発者向けにプレビュー版として提供されている。