[譯]如何在Web開發中使用Python
原文：HOWTO Use Python in the Web
摘要
這篇文檔展示了Python如何融入到web中。它介紹了幾種Python結合web服務器的方法，以及開發網站的一些常規做法。
“Web 2.0”是指由用戶主導網站內容的創作。自從這個概念興起以來，網絡編程就成為了一個熱門話題。一直以來，用Python創建網站是相當繁瑣的，所以也很少有人這么做。因此人們創建了許多框架和輔助工具來幫助開發者創建更快更可靠的網站。這篇HOWTO介紹了幾種Python結合web服務器創建動態內容的方法。當然，因為這個話題涉及的內容太廣，很難在單獨的一篇文檔里進行詳細的描述。所以這里就只對一些當前流行的庫作簡要的概述。
參見：這篇HOWTO試圖對Python的Web開發作一個概覽，但不能總是按預期及時地更新。Python的Web開發正在迅速發展，所以wiki上的Web Programming可能與近期的發展更為接近。
底層視角
當一個用戶訪問網站時，他們的瀏覽器會與網站的服務器進行連接（這稱為請求)。服務器在文件系統中尋找文件，並將其發送回用戶的瀏覽器（這稱為響應)。這就是底層HTTP協議的大致工作原理。動態網站不是基於文件系統中的文件，而是以程序為基礎。當請求到來，運行在服務器上的程序就會生成相應內容並發送回用戶。它們可以處理用戶的各種數據，例如列出公告板上的帖子，顯示你的郵件，配置軟件，或者只是顯示當前時間。這些程序能用服務器支持的任意語言完成。自從大部分的服務器開始支持Python，用Python創建動態網站就變得十分簡單了。
大多數的HTTP服務器是用C或者C++寫的，它們不能直接執行Python代碼，所以服務器和程序之間就需要有一座橋。網橋，或者更確切地稱為接口，決定了程序如何與服務器進行交互。
為了創建盡可能好的接口，人們作出了無數嘗試，但只有少數的幾個值得關注。
不是每一個服務器都支持所有的接口。許多服務器只支持老的，現在已經過時的接口。然而，它們經常可以通過第三方模塊擴展來支持新的接口。
常用網關接口
這個接口，通常被稱為“CGI”，是最古老的，幾乎被所有web服務器很好地支持着。在處理單個請求時，程序由服務器啟動，通過CGI與服務器進行通訊。因而每個請求來臨時都要花一定時間去啟動新的Python解釋器。這就使得整個接口在低負載狀態的時候才能正常使用。
CGI的優點在於它很簡單——用CGI寫一個Python程序大概就是三行代碼的事情。這種簡易性造成了一種誤解：它對開發者的幫助聊勝於無。
雖然還有可能用CGI寫程序，但已經不建議這么做了。通過使用本文稍后提到的WSGI，就能模仿CGI的方式寫程序，而且在迫不得已的時候，它們也能作為CGI運行。
參見：Python標准庫包含了一些模塊來幫助創建簡單的CGI程序：
Python的wiki有專門描述CGI腳本的頁面，里面有關於CGI在Python中的一些額外信息。
測試CGI的簡單腳本
你可以用這個簡短的CGI程序來測試你的服務器是否支持CGI。
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
# enable debugging
import cgitb
cgitb.enable()
print("Content-Type: text/plain;charset=utf-8")
print()
print("Hello World!")
根據你服務器的配置，你可能需要使用用.py或者.cgi擴展名來保存此代碼。出於對安全的考慮，此文件也可能需要放置在cgi-bin目錄中。
也許你想知道cgitb那行代碼有什么作用。這行代碼顯示良好的錯誤回溯，而不僅僅是崩潰時在用戶的瀏覽器上顯示“服務器內部錯誤”。這有利於進行debug，但存在一定的風險暴露某些機密的數據給用戶。基於這個原因，你不應該在生產環境中使用cgitb模塊。還有，終端用戶不會喜歡在瀏覽器上看到“服務器內部錯誤”這樣不倫不類的信息，所以你應該捕獲所有異常，並顯示合適的錯誤頁面。
在你自己的服務器上安裝配置CGI
如果你沒有自己的服務器，這就不適用於你。你可以檢查服務器是否如常工作，如果不是，你就可能需要聯系你網站的管理員。如果它是一個龐大的主機，你可以嘗試提交問題請求Python支持。
如果你就是自己的管理員，或者基於測試的目的想在自己的電腦上安裝CGI，你就必須自己進行配置。因為每個服務器的配置選項都不用，所以配置CGI沒有通用的方法。現在使用最廣的免費服務器是Apache HTTPd，或者簡稱Apache。通過系統的包管理工具，Apache可以輕易地安裝到幾乎所有的系統。lighttpd 則是另一個選項，據說有着更好的性能。在許多系統中，可以使用包管理工具來安裝這個服務器，所以不再需要手動來編譯它。
- 在Apache中，你可以在教程Dynamic Content with CGI中查看所有相關內容。在大多數的情況下，只配置
+ExecCGI就足夠了。這篇教程也提到一些最常見的問題。 - 在lighttp中需要使用能直接配置的CGI模塊。總的來說，只要合理地對
cgi.assign進行設置。
關於cgi腳本的常見問題
在運行CGI腳本的時候，時常會出現一些小的煩人的問題。有時看起來似乎正確的腳本不會像預期那樣工作，原因是某些小的隱藏問題很難被發現。
以下是一些潛在的問題：
- Python腳本沒有被標記為可執行的。當CGI腳本不能被執行時，大部分服務器不會運行它並發送結果給用戶，反而是讓用戶來下載它。在類Unix系統中，要正確運行CGI腳本，需要設置
+x位（修改執行權限）。使用chmod a+x your_script.py可能會解決問題。 - 在類Unix系統中，編程文件行結束必須是Unix風格的。這相當重要，因為服務器會檢查腳本文件的第一行(稱為shebang)，並嘗試運行那里指定的程序。如果是Windows的行結束(回車和換行Carriage Return&Line Feed, 所以稱為CRLF)，服務器就很容易混淆。因而你要將文件轉為Unix的行結束(只有換行Line Feed，LF)。在通過FTP上傳文件時，選擇文本模式而非二進制模式，轉換就可以自動完成。但更好的方式是在編輯器中用Unix風格的行結束保存文件。目前大多數的編輯器都支持這一選項。
- 你的Web服務器必須能夠讀取文件，還要保證相關權限的正確。在類Unix系統中，服務器常在用戶和用戶組為
www-data的狀態下運行。所以可以試着去修改文件的所有權，或者用chmod a+r your_script.py命令將文件改為可讀狀態。 - 在類Unix系統中，shebang(#!/usr/bin/env python)中解釋器的路徑必須正確。這行代碼在
/usr/bin/python中尋找Python，但如果該目錄不存在或者路徑不正確，查找都會失敗。你如果知道你的Python安裝在哪里，可以使用絕對路徑。命令whereis python和type -p python都能幫助你找到它的安裝位置。一旦你知道了正確的路徑，你就可以相應地修改shebang:#!/usr/bin/python。 - 文件中不能包含BOM(Byte Order Mark)。使用BOM意味着使用UTF-16或UTF-32編碼，但有的編輯器也將這些內容寫進UTF-8編碼的文件。BOM干擾了shebang一行，所以要確保你的編輯器不要將BOM寫到文件中。
- 如果Web服務器在使用mod_python，
mod_python可能會有問題。mod_python能夠自己處理CGI腳本，但也能成為問題的源頭。
mod_python
從PHP來的人經常很難抓住用Python進行Web開發的要領。他們第一時間想到的通常是mod_python，因為他們想mod_python等價於mod_php。事實上，它們之間有很多不同。mod_python做的是將解釋器嵌入到Apache的進程里，這樣就不用再為每個請求各啟動一個解釋器，從而加快了運行速度。另一方面，PHP經常混合着HTML，但Python不是。實際上，在Python中與之相當的是模板引擎。比起mod_php,mod_python本身要強大得多，它提供了更多的權限來訪問Apache的內部。在一個Python混合HTML的“Python服務器頁面”模式(與JSP相似)下，它可以模擬CGI工作。它還有一個“發布者”，可以指定一個文件來接收所有請求並決定接下來如何處理它們。
mod_python確實有很多問題。不同於PHP解釋器，Python解釋器在運行文件時是使用緩存的，所以修改文件時需要重啟服務器。另一個問題是關於Apache的工作原理 — Apache啟動子進程來處理請求，即使用不到Python，每個子進程依然要加載整個Python解釋器。這讓整個服務器運行得更慢了。另一個問題則是，如果不重新編譯mod_python，它就不能切換版本(例如從2.4升級到2.5)，理由是mod_python依賴於一個特定版本的libpython。還有，mod_python是綁定到Apache上的，所以用mod_python寫的程序不能輕易移植到在其他Web服務器上。
已經有很多原因解釋了應該避免用mod_python寫新的程序。在特定情況下，使用mod_python進行開發還是不錯的，但自從WSGI出現后，我們就可以在mod_python下運行WSGI程序了。
FastCGI和SCGI
FastCGI和SCGI嘗試以另一種方式解決CGI的性能問題。取代了在Web服務器中嵌入解釋器的做法，它們使用了一個長時間運行的后台進程。這還是一個能讓服務器與后台進程“說話”的模塊。既然后台進程獨立於服務器，它就可以用包括Python在內的任何語言來完成。使用的語言只需要一個能處理與Web服務器通信的庫。
正如SCGI本質上就是一個“簡單的FastCGI”，FastCGI和SCGI之間的差距非常小。因為僅有少數的服務器支持SCGI，大多數人使用工作方式相似的FastCGI。幾乎所有能應用於SCGI的也能應用於FastCGI，所以我們只討論后者。
如今，FastCGI不再被直接使用。就像mod_python,它只在WSGI的應用開發中使用。
安裝配置FastCGI
每個Web服務器都需要一個特定的模塊。
- Apache有mod_fastcgi和mod_fcgid。
mod_fastcgi是先出來的一個，但因為一些許可問題，有時候會被誤認為是收費的。mod_fcgid是一個體積更小，可兼容的替代選擇。 - lighttd發布了自己的FastCGI模塊和SCGI模塊。
- nginx也支持FastCGI。
一旦你將模塊安裝配置完成，就可以用下面的WSGI應用進行測試：
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
import sys, os
from html import escape
from flup.server.fcgi import WSGIServer
def app(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/html')])
yield '<h1>FastCGI Environment</h1>'
yield '<table>'
for k, v in sorted(environ.items()):
yield '<tr><th>{0}</th><td>{1}</td></tr>'.format(
escape(k), escape(v))
yield '</table>'
WSGIServer(app).run()
這是一個簡單的WSGI應用，但你需要先安裝[flup][https://pypi.python.org/pypi/flup/1.0]模塊來處理底層的FastCGI訪問。
參見：有一些關於用WSGI部署Django的文檔,其中多數的經驗可以復用到其他WSGI兼容的框架和庫。除了manage.py的部分需要修改，這里的例子可以直接使用。在Django中使用也是差不多的。
mod_wsgi
mod_wsgi是一次企圖擺脫底層網關束縛的嘗試。上文提到的FastCGI，SCGI和mod_python大多是用來部署WSGI應用的，mod_wsgi則是直接將WSGI應用嵌入到Apache服務器中。mod_wsgi是專門設計來托管WSGI應用。比起使用其他更底層，還需要膠水語言的模塊，使用它開發WSGI應用程序更為簡單。缺點是mod_wsgi僅限於Apache服務器；其他服務器則需要自己的mod_wsgi實現。
mod_wsgi支持兩種模式：嵌入模式，直接整合到Apache的進程中；守護進程模式，工作方式與FastCGI相似。
后退一步：WSGI
WSGI已經提到過幾次，這似乎意味着它很重要。事實上，它確實是。所以是時候來解釋它了。
網絡服務器網關接口(Web Server Gateway Interface)，或者簡稱WSGI，在PEP 333中有詳細定義，是目前進行Python網絡編程的最佳方式。雖然這對開發框架的程序員來說是一件好事，但一個普通的Web開發人員通常不需要跟它有直接的接觸。當選擇Web開發框架的時候，最好選擇一個支持WSGI的。WSGI最大的優點就是統一了應用程序的接口。如果你的程序兼容WSGI，這就意味這你外層使用的框架支持WSGI，你的程序可以部署到任意支持WSGI的Web服務器。你不再需要關心用戶使用的是mod_python，FastCGI，還是mod_wsgi，因為使用了WSGI的程序可以在任何的網關接口上運行。Python的標准庫也包含了它自己的WSGI服務器——wsgiref，一個可用作測試的小型服務器。
一個WSGI真正強大的特性是中間件。中間件是一個可以在軟件上添加各種功能的層。現在可以使用的的中間件相當地多。例如，你不再需要為自己的程序單獨編寫會話管理(HTTP 是一個無狀態協議，當一個用戶關聯數個HTTP請求時，你的應用程序必須使用會話創建和管理狀態)。壓縮也可以用類似的方式完成，已有中間件利用gzip壓縮你的HTML從而節省服務器寬帶。通過中間件，驗證的問題也可以輕松解決。
雖然WSGI可能看起來很復雜，但開始學習WSGI的收益是很大的，因為WSGI和它關聯的中間件已經解決了許多開發網站會遇到的問題。
WSGI服務器
用來連接像CGI和mod_python這樣的底層網關的代碼就稱為WSGI服務器。其中一個代表是flup，它支持FastCGI和SCGI，還有AJP。有一些服務器是用Python寫的，比如flup。但也存在用C完成的，可以作為替代使用。
現在可以使用的WSGI服務器有很多，所以一個用Python寫的Web應用幾乎可以部署在任何地方。這也是Python和其他web技術相比的一大優點。
參見：在WSGI homepage可以找到WSGI相關代碼的概述，其中還包含了一個涵蓋很廣的WSGI服務器列表。你可能對已經包含在標准庫中支持WSGI的模塊感興趣，即：
- wsgiref ——一些WSGI開發的小型實用工具和服務器
案例學習：MoinMoin
WSGI到底給web應用開發者帶來了什么？讓我們通過一個應用來了解。這個存在已久的Python應用最初並沒有使用WSGI。
MoinMoin是使用最廣的wiki軟件包中的一個。它創建於2000年，比WSGI還早了3年。舊的版本運行在CGI，mod_python,FastCGI上時都需要不同的代碼。
現在的版本添加了對WSGI的支持。通過WSGI，不需要膠水語言，MoinMoin可以部署到任意WSGI兼容的服務器。不同於前WSGI版本，現在MoinMoin作者可能在不知道的情況下就使用了WSGI服務器。
模板-視圖-控制器(Model-View-Controller)
術語MVC常在“框架foo支持MVC”這樣的描述中出現。比起具體特定的API，MVC更像是對代碼整體的一種組織形式。許多web框架使用這個模型來幫助開發者，給他們的程序帶來清晰的結構。稍大型的web應用就有相當多的代碼，所以從一開始擁有一個有效的結構是非常重要的。通過這種方式，只要提前了解MVC結構，即使是其他框架的用戶(或者甚至是其他語言，因為MVC不是Python獨有的)也能輕松地理解代碼。
MVC代表三個組件：
- 模型。能夠顯示和修改的數據。在Python的框架中，一般由對象關系映射器（OR-Mapper)中的類來代表。
- 視圖。這個組件的工作是向用戶展示模型中的數據。此組件通常由模板實現。
- 控制器。這是用戶與模型之間的一層。控制器對用戶的動作作出響應(例如打開一些特定的URL),如果需要就通知模型去修改數據，並告訴視圖部分要顯示什么內容。
雖然人們可能認為MVC是一個復雜的設計模式，但實際上它不是。它被用在Python中，是因為事實證明了它有助於創建簡潔，可維護的網站。
筆記：雖然不是全部Python框架明確支持MVC，但這不重要。創建網站的時候依然可以按照MVC模式，從用戶交互邏輯(控制器)和模板(視圖)中分離數據邏輯(模型)。因此也建議不要在模板中添加不必要的Python代碼。否則就違背了MVC模式的工作理念，令程序變得難以理解和修改。
參見：英文Wikipedia有一篇關於MVC設計模式的文章。文中詳細地列出了各種語言的web框架。
網站的組成成分
網站有着復雜的結構。為了減輕web開發者的負擔，讓項目更容易編寫和維護，許多工具被開發了出來。在其他語言的各種框架中都存在着類似的工具。一般情況下不會有人強迫開發者使用這些工具，而且通常“最好”的工具都是不存在的。某些工具會簡化開發網站的流程，所以適當選擇學習一部分還是不錯的。
參見：實際網站的組件要比這里提到的要多得多。Python的wiki中有一個叫Web Components的頁面，里面有關於這些組件的詳細敘述。
模板
只有少數的庫可以允許Python代碼和HTML混合。雖然這樣做很方便，但會導致代碼非常地難以維護。基於這個原因，模板就誕生了。在最簡單的情況下，模板只是帶有占位符的HTML文件。在填充完占位符后，HTML會被發送到用戶的瀏覽器上。
Python已經內置了一種方法來構建簡單的模板：
# a simple template
template = "<html><body><h1>Hello {who}!</h1></body></html>"
print(template.format(who="Reader"))
為了用龐雜的數據模型，判斷和循環結構來生成復雜的HTML頁面，像Python的for和if通常都是需要的。模板引擎正好支持這種復雜的模板。
許多用於Python的模板引擎都是獨立於框架的。其中一些定義成了某種容易上手的純文本編程語言，部分原因是它被限制在特定的作用域內。還有模板使用XML，這就保證了它的輸出一定是有效的XML。當然，其他種類的還有很多。
有些框架發布了自己的模板引擎或者推薦特定的一個。使用框架自己的或者推薦的通常都是不錯的。
流行的模板引擎包括：
參見：因為用Python來完成一個模板引擎是相當容易的，所以許多模板引擎為了引起開發者的關注而開始了相互競爭。在wiki頁面模板中列出了一個數量龐大且不斷增長的模板引擎列表。上面列出的三個被認為是”第二代“引擎，是了解模板引擎的好例子。
數據持久性
數據持久性，聽起來很復雜，其實就是儲存數據。數據可能來自博客條目的文本，布告欄的帖子，或者wiki頁面的正文。當然，在web服務器中有多種不同的方式來存儲信息。
因為在處理百萬級數據時有着有着良好的性能，像MYSQL或者PostgreSQL這樣的關系型數據庫經常被使用。但還存在着像SQLite一樣的小型數據庫。SQLite只使用一個單獨的文件，附帶於Python的sqlite3模塊。它沒有其他依賴。對於較小的站點，SQLite就足夠了。
關系型數據庫通過一種稱為SQL的語言進行查詢。一般來說，Python程序員不太喜歡SQL，因為他們喜歡使用對象。通過使用一種叫ORM(Object Relational Mapping)的技術，Python對象可以保存在數據庫中。在后台，ORM將全部面向對象的訪問轉化為SQL代碼，所以開發者不用注意太多。大多數的框架在使用各種ORM，而且使用的效果確實不錯。
第二種可能就是將數據存儲在普通的純文本文件（有時候稱為“flat files”）。對於簡單的網站而言，這很容易實現，但如果網站經常更新數據，那就表現得不如盡人意了。
第三種可能則是使用面向對象的數據庫（也稱為”對象數據庫“）。這種數據庫存儲對象數據的方式與程序運行時對象在內存中結構化的方式接近。（相比之下，ORM將對象數據存儲為表中的數據行以及行之間的關系。）直接儲存對象的優點是幾乎所有的對象都可以直接保存。反觀關系型數據庫，一些特別的對象就很難被表達。
框架通常都會對選擇哪種存儲數據方式的問題上給點建議。除非有特殊的應用場合，遵循它給的建議一般都能很好地滿足存儲需求。
參見：
- Persistence Tools列出了在文件系統中存儲數據的各種方式。其中某些模塊被包含在標准庫中
- Database Programing幫助開發者選擇一種方式來保存數據
- SQLAlchemy，Python中最強大的OR-Mapper。還有Elixir，簡化了SQLAlchemy的使用
- SQLObject，另一個流行的OR-Mapper
- ZODB和Durus，兩個面向對象的數據庫
框架
在為網站運行編寫代碼的過程中，需要涉及到多種服務。不管網站的復雜性如何，它的目標是什么，提供特殊服務的代碼其工作方式都是一樣的。在web開發中，將常見問題的解決方法抽象出來轉化為可復用的代碼就叫做框架。也許你聽說過最著名的web開發框架是 Ruby on Rails， 但Python也有自己的框架。其中有部分是受Rails啟發或者是借鑒了Rails的想法。不過在Rails誕生之前，許多框架就已經存在了很長時間。
原來Python Web框架傾向於整合開發網站需要的所有服務，並集成一系列的開發工具。但沒有哪兩個web框架能夠相互協作：沒有經過深思熟慮的重構后，用A框架的開發的程序是不能部署在B框架上的。這種趨勢推動了“minimalist”（極簡主意）web框架的發展。這類型的框架只保留了讓代碼與http協議通信的工具，其他服務則需要在上層通過分開的組件逐一添加。為了讓框架之間能彼此協作，一些標准應運而生。比如某個標准，可以允許不同的模板引擎相互替換使用。
隨着WSGI的出現，Python Web框架一直在向基於WSGI標准的互操作性上發展。現在不論是“全棧”的（提供開發最復雜網站需要的所有工具）還是微型的（minimalist），或者其他任意類型的web框架，都是由可運行在多個框架上的可復用組件集合而成。
多數的用戶會可能選擇一個擁有活躍社區的“全棧”框架。這些框架都漸漸地有了友好的文檔，並且提供了一種最簡流程來引導開發者在最短時間內完成功能齊全的網站。
一些值得關注的框架
現在框架的數量多到難以置信，所以這里不可能都一一提及。相對地，我們只簡單地介紹幾個最流行的框架。
Django
Django是一個包含了數個緊密耦合組件的框架。其中的組件都是重新寫的，相互配合得很好。Django提供的ORM相當強大，而且簡單易用。內置的在線用戶管理界面能夠讓人們通過瀏覽器編輯數據庫中的數據。為了照顧不會Python的網頁設計人員，它的模板引擎是基於文本的。它還支持模板繼承和過濾器（類似於Unix的管道）。Django附帶了許多便利的特性，例如通過生成RSS feeds和generic views，幾乎不用寫Python代碼就可以創建一個網站。
Django還擁有一個龐大的國際社區，里面的成員創建了無數的站點。為了拓展Django的常用功能，還存在着大量的插件。這部分歸功於Django友好的在線文檔和Django book。
筆記：雖然Django是MVC設計的框架，但它命名的方式有些不一樣，你可以在Django FAQ中找到相關敘述。
TurboGears
Python另一個流行的web框架是TurboGears。TurboGears使用現有的組件並用膠水語言組合它們，通過這種方法來實現無縫連接。在選擇組件的時候，TurboGears給予了用戶充分的自由。例如ORM和模板引擎都可以改為使用非默認的軟件。
可以在TurboGears documentation種找到相關文檔，里面還有視頻教程。TurboGears也有一個活躍的社區，能回答最相關的問題。TurboGears book已經出版，這同樣是一個學習TurboGears很好的起點。
TurboGears最新的版本是2.0，在WSGI支持和基於模組的架構的方向上更進一步。TurboGears2的WSGI技術棧是基於另一個流行的組件兼容的web框架——Pylons。
Zope
框架Zope是一個“古老原始”的框架。它的化身Zope2是一個高度集成的全棧框架。它一個最有趣的特性是它與一個強大的面向對象數據庫ZODB（Zope Object Database）緊密結合。由於其高度的集成性，Zope最終的生態圈稍微有些孤立：為Zope編寫的代碼很難能在用在Zope以外的地方，反之亦然。Zope 3開始致力於解決這個問題。Zope 3將Zope重寫成一套清晰獨立的組件。這項工作開始於WSGI標准建立之前，但項目Repoze為Zope 3添加了對WSGI的支持。Zope的組件已經在背后默默地工作了很多年，Zope 3則將這些組件開放給更廣泛的Python社區。甚至促成一個新的基於Zope組件的框架：Grok
當前最強大和最受歡迎的內容管理系統——Plone，就是基於Zope實現的。
其他值得關注的框架
實際可用的框架當然不止這些，還有許多其他的框架值得一試。
另一個被提到的框架是Pylons。Pylons很像TuroGears，但更強調靈活性，為此也犧牲了易用性。在Pylons中，幾乎每一個組件都可以被替換。這就導致了每個單獨的組件都需要很多文檔。Pylons是建立在Paste的基礎上，而Paste是一個方便WSGI使用的工具集。
這還不是所有。你可以在Python wiki中找到更多最新的信息。
參見：Python wiki包含了一個范圍很廣的web 框架列表。大部分框架都有自己的郵件列表和IRC頻道，在對應項目的網站就能找到這些信息。