Pylons と repoze.bfg の合併に関する覚え書き
Original text is written by Ben Bangert, on November 12, 2010.
Author: | Ben Bangert |
---|---|
Translator: | Nozomu Kaneko <nozom.kaneko@gmail.com> |
Note
この文書は Ben Bangert の blog 記事 の翻訳です。 原文はこの文書のソースコードに含めてあります。
Pylons-discuss メーリングリストを読む時間がない人にとってはニュースかも しれないが、 Pylons と repoze.bfg ウェブフレームワークが合併作業中で あると公表できて興奮している。もしこのことに関して初めて聞いたとし ても心配しないでほしい。それは今からほんの1週間前に Pylons メーリング リスト上で公表されたのだ。
公表以来、私は様々な多くのフィードバックをもらった。何人かの人々は Pyramid (“Pylons 2.0” に相当する中核パッケージ) を見て迅速に (通常は脊 髄反射的に) 反応した。そのうちのいくらかは伝達不足によるもので、一部は 多くのことが既に行われていたことが原因だったと思う。Rails が Merb と 合併したときのように、他の言語で他のフレームワークが合併した場合、 公表は単にそれだけだった。その時点で示すべきコードはなく、準備ができた 時にはそれが素晴らしいものになるだろうという単なる約束しかなかった。
この合併には、対照的に中核機能の巨大な塊に対して開始するための土台が 既にあった。その結果、人々は私たちが行っていることがすでに「完了」して いる、あるいはそれに近いと見なした。作成された多数のドキュメンテーショ ンの完成度の高さから、「Pylons 1.0 から Pyramid への移植」ガイドができ ていないことを奇妙に感じた。実際には、 Pyramid は断じて完成していない 。 Pyramid が多くの Pylons ユーザの持つ期待に応えられるようになるまでは、 まだまだたくさんの仕事が残されている。 Pyramid に対して行うべき改良は まだあり、Pylons ユーザが慣れている feature セットのためにほとんど常に 使用することになる追加のパッケージもある。
将来の期待のより良い管理を try and help するために、 私は Pylons ユーザはいつ Pyramid に移植すべきかに関するいくつかの考え をまとめた 。パッケージが楽に移行できる準備が整い、 「移植ガイド」の準備ができ次第、さらに公表を行なうつもりだ。
多くの Pylons ユーザは、どの feature が ‘pylons’ パッケージから来た ものか、あるいは Pylons が依存する他の「パッケージ」から来たものかを 意識していない。多数派の確信に反して、 Pylons の中に存在する大多数の feature は、実際には他のパッケージから来ている。ほとんどの feature が Pylons パッケージから来ているというこの誤った確信により、私の未来の開発 時間の多くが Pyramid 周辺の feature /パッケージを加えることに費やされる ので、 Pylons は何となく 死んだ と思う人がいる。これは事実とは異なる。
第一に、 Pylons ウェブフレームワークは主として Paste, PasteScript, PasteDeploy, WebOb, WebError, Routes, WebHelpers, Mako, SQLAlchemy の 間の小さな (~1000 LoC) グルー層である。一部の人々は大抵 Mako/SQLAlchemy を交換することになるが、全般にこれは共通の「Pylons スタック」だ。過去 数年にわたる Pylons 中のほとんどの新しい feature は、実際には WebHelpers, WebError あるいは Routes への追加による。これらのパッケージすべては、 これまで通り開発が続けられる。したがって、「死」は生じていない。
第二に、現在から過去6か月の間、提出されたパッチ、報告されたバグ、 あるいは他の機能要望はほとんどなかった。色々な意味で、中核パッケージ 自体に多くの feature を加えることに関して Pylons は「完成している」。 私が Pylons-discuss メーリングリスト上で公表 したように、 Pylons コードベースはいくつかの設計上の問題にぶつかった。 かなり多数のユーザから要求を聞いた (そして自分自身も必要とした) 拡張性 に関する feature の追加を、既存の設計に retro-fit することができなかった。 興味がある人は、将来のいくつかのブログポストのプレビューとなる、拡張性 のためのサブクラス化に関する前のエントリーをぜひ読んでほしい。私はさらに、 多くの主要な Python ウェブフレームワークでも扱うのに苦労している拡張性を 扱うための Python におけるデザインパターンについても書こうと思っている。
私は、 Pylons プロジェクトの将来に非常に興奮している。それは Python ウェブフレームワーク技術を開発する新しい包括的な (over-arching) 組織だ。 コアは Pyramid と、その周辺に構築された追加の feature および機能性に なるだろう。開発者チームは既に何人かの長年の貢献者とともに素早く拡張して おり、合同チームを持つことは、私たちが急速に進歩することを明確に助けている。
私の主なゴールのうちの1つは、コミュニティーからの貢献を促進し容易にする ことだ。そのため、できるだけ Pylons プロジェクトへの貢献セクションを 充実させている 。 私たちは Python 開発のより高い標準を強調しているので、他のプロジェクト はともかく、これは私たちが早急に取り組むべき領域であると信じている。
Django は、 Django への貢献 の方法 を示したドキュメンテーションにおいて、高いハードルを設定する良い仕事をした。 それは、コミュニティーポリシーを明確に定義したことで多くの賞賛に値する。 私たちが非常に価値があると考える部分で抜けているのは、コア開発者は 一般に、パッチを受け取った場合非常に口うるさくなるということだ ... あなたのコードをテストする 方法に対して。 Pylons プロジェクトは、 Tres Seaver によって書かれたかなり徹底的な テスト教義 を採用した。 ただし、個人的にはユニットテストを書くことに関してあまり強く推奨できない。 正確に あなたのコードをテストする方法 に関してさらに詳しく述べた他の 多くのポストも見てみると良いだろう。多くの開発者 (自分を含む) は、100% のテストカバレージを通るコードを書くことができる ... しかし、それは脆い テストコードではないか? テストが使用しているある賢すぎるマクロが失敗した 場合に失敗する傾向にないか? ユニットテストの設計について良く書かれた 一連の例を見ることは、 common gotcha を回避するために貢献者 (また開発者 一般) は誰でも絶対に親しんでおくべきことだ。
Pyramid へのより優しい入門を望む人々のために (ドキュメントは非常に冗長 かつ詳細で、全く主義主張が強くない)、新しい feature およびそれらを利用 する方法に関してもっとブログを書くつもりだ。どうか待ってほしい。私は、 待ち受けているものに多くの人々が興奮するだろうと思っている。