プロジェクトの公式グループで急速に議論が展開されたため、情報は浮上した。 具体的には、次のことが判明しました。
- 最近1.0のリリースに達したPylons Webフレームワークは、現在の形では開発を停止します。 1.xブランチの完全なサポートが今後数年間行われるという事実にもかかわらず、プロジェクトのアーキテクチャの変更や革新は行われません。
- 名前「Pylons」は、傘下のブランド「project」Pylonsに関連付けられます。これは、コミュニティに参加したいすべての技術の開発をカバーします（同様のパスは、傘「Pocoo」の下でのプロジェクトの開発です。 Jinja 2テンプレートエンジンとSphinx pythonプロジェクトドキュメントシステム）;
- 今日のPylonsプロジェクトの主要な技術はPyramid web frameworkであり、 BSDから派生したライセンスの下で配布されています。
このメッセージを使用して、プロジェクトでPylonsを使用または使用する予定のすべての開発者に、このWebフレームワークの現在の状況について通知したいと思います。
メンテナーからの公式な発表はまだありませんが、近い将来に予想されるはずです。Pylons-1.xの使用計画を確認することを強くお勧めします。
新しいプロジェクトの観点からは、Pyramidに参加するか、他の代替技術（同じWerkzeug、Django、およびPylonsから派生したものではない他のフレームワーク）を選択することは明らかに価値があります。
現在Pylonsを開発している人にとって、さらなるアクションのための多くのオプションはありません：
- フレームワークの機能が許す限り、1.xブランチにとどまり、冷静にプロジェクトを実行します。
それでも、現在の状態では、Pylonsは非常に安定しており、最小限（2000行を超えるコード行で構成されています）であり、互換性のあるすべてのサードパーティモジュールは引き続き積極的に開発されています。 必要に応じて、増加したニーズに合わせてフレームワークを完成させることは難しくありません。 - プロジェクトを新しいトラックに転送してみてください（
そうです...勇気と動機が許せば、すぐにRoRに移行できます ）。 ただし 、まだ規模が拡大しておらず、凍結されたプラットフォームにしっかりと「スタック」していません。
原則として、2番目のオプションに興味がある人のために、以下は
、新しいプロジェクトの公式ドキュメントを最初に知った後、彼らが何とか学んだことを非常に簡潔に語ったものです。
ピラミッドの本質について
PyramidはBFG Webフレームワーク（repoze.bfgとしても知られています）から生まれました。これはZopeプラットフォームの子孫ですが、DjangoとPylonsの強い印象の下で開発されました。 今年、BFGとPylonsの開発者は、両方のプロジェクトの努力と既存の開発を組み合わせて、新しいフレームワークを作成することを決定しました（興味深いが、既存のドキュメントでは過去形を使用しています-
「Pyramidはrepoze.bfgとして知られていました; 2010年末にPylonsプロジェクトに統合されました 。 開発者は、最大の注目を集めたプロジェクトの主要な特性として、次のことに注意します。
- 低エントリーしきい値。
- ミニマリズム;
- 速度（パフォーマンス）;
- 最も完全で最新のドキュメント（開発者は、コードベースが小さいため、ドキュメントを完全で最新の状態に完全に維持できることに注意してください）。
- 信頼性（各リリースにはユニットテストで100％のコードカバレッジがあります）;
- 開放性。
アーキテクチャによって、Pyramidは他のWSGIツールキットのDjango / Pylons /とZopeプラットフォームの中間に位置しています。その結果、開発者はシステムのいくつかのコンポーネントを設定するアプローチを自由に選択できます。
- Zope構成ファイル（ZCML、XMLベースのフォーマット）を介してWebアプリケーションをセットアップする宣言スタイルがサポートされています...
- ...同時に、フレームワークでは、INI構成でPylonsの純粋に必須のアプローチを使用できます（オブジェクトを手動で作成し、INI構成のパラメーターに従ってオブジェクトを設定し、適切な場所でこれらのオブジェクトのメソッドを呼び出す）。
- トラバーサルアルゴリズムは 、リクエストハンドラーの検索と呼び出しのためにサポートされています（要求されたURLに反映された階層に厳密に従って、モデルオブジェクトのグラフに沿って「ルートオブジェクトからネスト」）。 同様のアプローチがCherryPyフレームワークでも使用されています...
- ...同時に、PylonsおよびDjangoで行われているように、パターンに従ってURLをルーティングする標準的な方法（URLディスパッチ）を使用することができます。また、トラバーサルアルゴリズムとパターンによるルーティングの混合アプローチも使用できます。
- Pyramidは、アーキテクチャMVCパターンを使用しますが、わずかに変更された形式です。 そのため、コンポーネント「View」と「Controller」は1つのエンティティ「View」に結合され、「Model」に格納されたデータを表現しますが、「View Callable」と「View Handler」という2つの異なるコンテキストを持ちます。
- View Callableは呼び出し可能なオブジェクト（関数、または特定の__call__メソッドを持つクラス）であり、着信要求の処理を担当します。 Pylonsアプリケーションで最も近いものは、コントローラークラス内のアクションメソッドです。 したがって、コントローラークラス自体はPyramidがView Handlerと呼ぶものに最も近いアナログです。
- Pylonsのように、フレームワークは、データを保存および管理するための特定のテクノロジーを開発者に課しません。
Pyramid自身のコードベースは、約5,000（5万）行のコードで構成されていますが、Pylons-1.0では2,000行をわずかに超えています。 他のすべての機能は、プロジェクトの依存関係のリストに含まれているサードパーティのパッケージにより実装されています。
以下は、Pylons-1.0およびPyramid-1.0a1に同梱されているパッケージのリストです。 出力は、
virtualenvおよび
pipユーティリティを使用して取得します。
標準装備パイロン
ビーカー== 1.5.4
FormEncode == 1.2.3dev
マコ== 0.3.5
MarkupSafe == 0.11
貼り付け== 1.7.5.1
PasteDeploy == 1.3.4
PasteScript == 1.7.3
Pygments == 1.3.1
パイロン== 1.0
ルート== 1.12.3
Tempita == 0.5dev
WebError == 0.10.2
WebHelpers == 1.2
WebOb == 1.0
WebTest == 1.2.3
デコレータ== 3.2.0
鼻== 0.11.4
simplejson == 2.1.2
wsgiref == 0.1.2
標準装備ピラミッド
ビーカー== 1.5.4
カメレオン== 1.2.13
マコ== 0.3.5
MarkupSafe == 0.11
貼り付け== 1.7.5.1
PasteDeploy == 1.3.4
PasteScript == 1.7.3
WebOb == 1.0
ピラミッド== 1.0a1
repoze.lru == 0.3
translationstring == 0.3
金星== 0.4
wsgiref == 0.1.2
zope.component == 3.10.0
zope.configuration == 3.7.2
zope.deprecation == 3.4.0
zope.event == 3.5.0-1
zope.i18nmessageid == 3.5.3
zope.interface == 3.6.1
zope.schema == 3.7.0
-パイロン：19。
ピラミッド：20。
定量的には、状況はそれほど変化していません。Pylonsと同様、Pyramidはサードパーティの技術とWSGIスタックに積極的に依存していますが、構造的な変化は明らかです。 それらが完成したPylonsアプリケーションの移植の複雑さにどれだけ影響するかを言うのは難しいです。 これまでのところ、開発者は
、こうした急進的な変更を行うように促した理由のみに言及
し （
詳細はこちら ）、すでに作成されたアプリケーションの機能を失うことなく、Pylons 1.xユーザーにPyramidへの移行計画を提供することを約束します。
UPD： Pylons-1.0からの
非公式の移行ガイドがネットワークに登場しました。 ただし、トピックの作成者によるこのソリューションの整合性とパフォーマンスはまだテストされていません。
UPD： 真空での球面試験 。