前言
大多數Python開發者至少都寫過一個像工具、腳本、庫或框架等對其他人也有用的工具。我寫這篇文章的目的是讓現有Python代碼的開源過程盡可能清晰和無痛。我不是簡單的指——“創建一個GitHub庫，提交，在Reddit上發布，每天調用它”。在本文的結尾，你可以把現有的代碼轉換成一個能夠鼓勵他人使用和貢獻的開源項目。
喜歡的話就轉發在下方評論留下你的見解哦！
然而每一個項目都是不同的，但其中將現有代碼開源的流程對所有的Python項目都是類似的。在另一個受歡迎的文章系列里我寫了“以正確方式開始一個Django項目”，我將概述在開源Python項目我發現的有必要的步驟。
工具和概念
特別是，我發現一些工具和概念十分有用或者說是必要的。下面我就會談及這方面主題，包括需要運行的精確的命令和需要設置的配置值。其終極目標就是讓整個流程簡單明了。
項目布局
當準備一個項目時，正確合理的布局（目錄結構）是十分重要的。一個合理的布局意味著想參與開發者不必花時間來尋找某些代碼的位置; 憑直覺就可以找到文件的位置。因為我們在處理一個項目，就意味著可能需要到處移動一些東西。
讓我們從頂層開始。大多數項目都有很多頂層文件（如setup.py, README.md, requirements等等）。每個項目至少應該有下面三個目錄：
為了更好理解文件該如何組織，這里是一個我的簡單項目：sandman 布局快照。
如你所看到那樣，這里有一些頂層文件，一個docs目錄（建立一個空目錄，因為sphinx會將生成的文檔放到這里），一個sandman目錄，以及一個在sandman目錄下的test目錄。
setuptools 和 setup.py文件
setup.py文件，你可能已經在其他包中看到過，被distuils包用來安裝Python包的。對于任何一個項目，它都是一個很重要的文件，因為它包含了版本，包依賴信息，PyPi需要的項目描述，你的名字和聯系信息，以及其它一些信息。它允許以編程的方式搜索安裝包，提供元數據和指令說明讓工具如何做。
setuptools包（實際上就是對distutils的增強）簡單化了建立發布python包。使用setuptools給python包打包，和distutils打包沒什么區別。這實在是沒有任何理由不使用它。
setup.py應該放在你的項目的根目錄。setup.py中最重要的一部分就是調用setuptools.setup，這里面包含了此包所需的所有元信息。這里就是sandman的setup.py的所有內容
（感謝Christian Heimes的建議讓setup.py更符合人們的語言習慣。反過來，也讓我借用其他的項目一目了然了。)
大多數內容淺顯易懂，可以從setuptools文檔查看到，所以我只會觸及"有趣"的部分。使用sandman.__version__和gettinglong_description方法（盡管我也記不住是哪一個，但是卻可以從其它項目的setup.py中獲得）來減少我們需要寫的引用代碼。相反，維護項目的版本有三個地方(setup.py, 包自身的__version__， 以及文檔)，我們也可以使用包的version來填充setup里面的version參數
long_description被Pypi在你項目的PyPI主頁當做文檔使用。這里有其他一個文件，README.md，其中包含幾乎相同的內容，我使用pandoc依據README.md自動生成README.rst，因此我們只需看README.rst就行了，并將它的內容設置為long_description。
py.test (上面討論過) 中有一個特殊的條目（pytest類）設置允許Python檢查setup.py可否正常工作。這段代碼直接來自py.test指導文檔。
文件中的其他內容都是在設置文檔中描述的安裝參數。
其他的setup.py參數
有一些sandman 用不到的啟動參數，在你的包里可能會用到。舉個例子，你可能正在分派一些腳本并希望你的用戶能夠從命令行執行。在這個例子中，腳本會和你其他的代碼一起安裝在正常的site-packages位置。用戶安裝完后，沒有其他的簡單方法運行它?；谶@一點，setup可以帶有一個的腳本參數來指明Python腳本應該如何安裝。在包中安裝一個調用go_foo.py的腳本，這個用來啟動的調用包括下面這行：
確保在腳本中填入相對路徑，并不僅僅是一個名稱 (如scripts = [''scripts/foo_scripts/go_foo.py'']).同樣，你的腳本應該以"shebang"行和"python"開始，如下：
distutils將會在安裝過程中自動用當前解釋器位置取代這一行。
如果你的包比我們這里討論的要復雜，你可在官方文檔中參看啟動工具文檔和分布python模塊。
在這兩者中，你可以解決一些你可能會遇到的問題。
代碼管理：git， 項目管理：gitHub
在“以正確的方式開始一個Django項目”中，我建議版本控制使用git 或者 mercurial。如果對于以共享與貢獻的項目來說，只有一個選擇：git。事實上，從長遠來說，如果你想人們能使用和參與貢獻，那么不僅使用git很有必要，而且，你也能夠使用GitHub來管理維護你的項目。
這并不是夸大其詞（盡管很多人會以它為嚼頭）。然而，管它好與差，git和GitHub事實上已經成為了開源項目的實際標準了。GitHub是很多潛在的貢獻者最想注冊的和最熟悉的。所以，我深信，這并不是掉以輕心，而是深思熟慮的產物。
新建一個README.md文件
在GitHub的代碼倉庫中，項目的描述是從項目的根目錄中的:README.md文件獲取的。這個文件應該包含下面幾點：
它(README)讀起來很傻的感覺，但是確是一個很重要的文件。它可能是你未來的用戶或者貢獻者首先從它了解你的項目的?；ㄐr間來寫一個清楚明白的說明和使用GFM（GitHubFlavoredMarkdown）來使它更好看。實際上，如果使用原生的Markdown來寫文檔不爽，那么可以在Github上使用立即預覽來創建或者修改這個文件
我們還沒觸及列表中的第二和第三項（ReadTheDocs和TravisCI），你會在接下來看到。
使用"Issues"頁
跟生活中的很多事情一樣，你投入GitHub越多，你收獲的越多。因為用戶會使用GitHub的“Issues”頁面反饋bug，使用該頁面跟蹤特性要求和改進是很有意義的。
更重要的是，它允許貢獻者以一種優雅的方式看到：一個可能實現特性的列表以及自動化的管理合并請求流程（pull request）。GitHub的issues可以與評論、你項目里的其他issues及其他項目里的issues等交織，這使得“issues”頁面成為一個有關所有bug修復、改進和新特性要求信息匯總的地方。
確?！癐ssues”及時更新，至少及時回應新的問題。作為一個貢獻者，沒有什么比修復bug后看著它呈現在issues頁面并等待著被合并更有吸引力的了。
使用git-flow這個明智的git工作流
為使事情對自己和貢獻者更容易，我建議使用非常流行的git-flow分支模型。
概述
開發分支是你工作的主要分支，它也是將成為下一個release.feature的分支，代表著即將實現的新特性和尚未部署的修復內容（一個完整的功能分支有開發分支合并而來）。通過release的創建更新master。
安裝
按照你系統平臺的git-flow安裝指導操作，在這里。
安裝完后，你可以使用下附命令遷移你的已有項目
Branch細節
腳本將詢問你一些配置問題，git-flow的默認建議值可以很好的工作。你可能會注意到你的默認分支被設置成develop?，F在，讓我們后頭描述一下git-flow…嗯，flow，更詳細一點。這樣做的最簡單的方法是討論一下不同的分支及模型中的分支類型。
Master
master分支一直是存放“生產就緒”的代碼。所有的提交都不應該提交到master分支上。當然，master分支上的代碼只會從一個產品發布分支創建并結束后合并進來。這樣在master上的代碼一直是可以發布為產品的。并且，master也是一直處于可預計的狀態，所以你永遠不需要擔心如果master分支修改了而某一個其他分支沒有相應的修改。
Develop
你的大部分工作是在develop分支上完成的。這個分支包含所有的完成的特性和修改的bug以便發布；每日構建或者持續集成服務器需要針對develop分支來進行，因為它代表著將會被包含在下一個發布里的代碼。
對于一次性的提交，可以隨便提交到develop上。
特性
對于一些大的特性，就需要創建一個特性分支。特性分支從develop分支創建出來。它們可以是對于下一個發布的一些小小的增強或者更進一步的修改。而這，依然需要從現在開始工作。為了從一個新的分支上開始工作，使用：
這命令創建了一個新的分支：feature/<feature name>。通常會把代碼提交到這個分支。當特性已經完成并且準備好發布的時候，它就應當用一下的命令將它合并會develop分支：
這會把代碼合并進develop分支，并且刪除 feature/<feature name>分支
Release
一個release分支是當你準備好進行產品發布的時候從develop分支創建出來的。使用以下的命令來創建：
注意，這是發布版本號第一次創建。所有完成的，準備好發布的分支必須已經合并到develop分支上。在release分支創建后，發布你的代碼。任何小的bug修改需要提交到 release/<release number>分支上。當所有的bug被修復之后，運行以下的命令：
這個命令會把你的release/<release number> 分支合并到master和develop分支，這意味著你永遠不需要擔心這幾個分支會缺少一些必要的產品變更（可能是因為一個快速的bug修復導致的）。
Hotfix
然而hotfix分支可能會很有用，在現實世界中很少使用，至少我是這樣認為的。hotfix就像master分支下創建的feature分支： 如果你已經關閉了release分支，但是之后又認識到還有一些很重要的東西需要一起發布，那么就在master分支（由$git flow release finish <release number>創建的標簽）下創建一個hotfix分支，就像這樣：
當你完成改變和增加你的版本號使之獨一無二(bump your version number)，然后完成hotfix分支：
這好像一個release分支（因為它本質上就是一種release分支），會在master和develop分支上提交修改。
我猜想它們很少使用的原因是因為已經存在一種可以給已發布的代碼做出修改的機制：提交到一個未完成的release分支。當然，可能一開始，團隊使用git flow release finish .. 太早了，然后第二天又發現需要快速修改。隨著時間的推移，他們就會為一個release 分支多留一些時間，所以，不會再需要hotfix分支。另一種需要hotfix分支情況就是如果你立即需要在產品中加入新的特性，等不及在develop分支中加入改變。不過（期望）這些都是小概率事件。
virtualenv和virtualenvwrapper
lan Bicking的virtualenv工具事實上已經成為了隔離Python環境的標準途徑了。它的目標很簡單：如果你的一臺機子中有很多Python項目，每個都有不同的依賴（可能相同的包，但是依賴不同的版本），僅僅在一個Python安裝環境中管理這些依賴幾乎是不可能的。
virtualenv創建了一個“虛擬的”Python安裝環境，每個環境都是相互隔離的，都有自己的site-packages, distribute和 使用pip安裝包到虛擬環境而不是系統Python安裝環境。 而且在你的虛擬環境中來回切換只是一個命令的事。
Doug Hellmann的virtualenvwrapper使創建和管理多個虛擬環境更容易的隔離工具。讓我們繼續前進，馬上安裝這兩個工具：
如你所見，后者依賴于前者，所以簡單的安裝virtualenvwrapper就足夠了。注意，如果你使用的是Python3，PEP-405通過venv包和pyvenv命令提供了Python原生虛擬環境的支持，在python3.3中已實現。你應該使用這個而不是前面提到的工具。
一旦你安裝了virtualenvwrapper，你需要添加一行內容到你的.zhsrc文件(對bash用戶來說是.bashrc文件)：
這樣在你的shell中增加了一些有用的命令（記得第一次使用時source一下你的.zshrc文件以使它生效）。雖然你可以使用mkvirtualenv命令直接創建一個virtualenv，但使用mkproject [OPTIONS] DEST_DIR創建一個“項目”將更有用。因為我們已經有一個現有的項目了，所有我們只需為我們的項目創建一個新的virtualenv，下附命令可以達到這效果：
你會注意到你的shell提示符在你的virtualenv之后（我的是“ossproject”，你可以使用任何你喜歡的名字）。現在任何通過pip安裝的模塊將安裝到你的virtualenv下的site-packages。
要停止在你的項目上工作并切換回系統使用deactivate命令。你會看到命令提示符前你的virtualenv名字消失了。要重新回到你的項目上工作的話運行workon <project name>，你會回到你的virtualenv。
除了簡單地為你的項目創建virtualenv，你還會用它做其他事：生成你的requirements.txt文件，使用requirements.txt文件和-r標識可安裝所有項目的依賴項。要創建該文件，在你的virtualenv運行以下命令（一旦你代碼和virtualenv一起工作，就是那里）：
你會得到一個所有你項目需要模塊的列表，它以后可以被setup.py文件使用列出你的依賴關系。這里有一點需要注意：我經常在requirements.txt中將“==”改為“>=“，這樣代表“我正使用包的任何的后來版本”。你是否應該或需要在項目這樣做取決于實際情況，但我應該指出來。
將requirements.txt提交到你的git代碼庫中。此外，你現在可以添加這里的列出的包列表作為install_requirement參數的值到setup.py文件中的distutils.setup。這樣做我們可以確保當上傳包到PyPI后，它可以被pip安裝并自動解決依賴關系。
使用py.test測試
在Python的自動測試系統里有兩個主要的Python標準單元測試包（很有用）的替代品：nose和py.test。兩個方案都將單元測試拓展的易于使用且增加額外的功能。說真的，哪個都是很好的選擇。我更喜歡py.test因為下述幾個原因：
注意
如果你已經有了一個自動測試的解決方案那繼續使用它吧，跳過這一節。但請記住以后的章節你將被認為在使用py.test測試，這可能會影響到配置值。
測試安裝
在測試目錄里，無論你如何決定都要有這個目錄，創建一個名為test_<project_name>.py的文件。py.test的測試發現機制將把所有test_前綴的文件當做測試文件處理（除非明確告知）。
在這個文件里放什么很大程度上取決于你。寫測試是一個很大的話題，超出這篇文章的范圍。最重要的，測試對你的和潛在的捐助者都是有用的。應該標識清楚每個用例是測試的什么函數。用例應該以相同的“風格”書寫，這樣潛在的貢獻者不必猜測在你的項目中他/她應該使用三種測試風格中的哪種。
覆蓋測試
自動化測試的覆蓋率是一個有爭議的話題。一些人認為它給出了錯誤的保證是一個毫無意義的度量，其他人認為它很有用。在我看在，我建議如果你已經使用自動化測試但從來沒有檢查過你的測試覆蓋率，現在做這樣一個練習。
使用py.test，我們可以使用Ned Batchelder的覆蓋測試工具。使用pip安裝pytest-cov。如果你之前這樣運行你的測試：
你可以通過傳遞一些新的標識生成覆蓋率報告，下面是運行sandman的一個例子：
當然不是所有項目都有100%的測試覆蓋率（事實上，正如你讀到的，sandman沒有100%覆蓋），但獲得100%的覆蓋率是一個有用的練習。它能夠揭示我之前沒有留意的缺陷與重構機會。
因為，作為測試本身，自動生成的測試覆蓋報可以作為你持續集成的一部分。如果你選擇這樣做，部署一個標記來顯示當前的測試覆蓋率會為你的項目增加透明度（大多數時候會極大的鼓勵他人貢獻）。
使用Tox進行標準化測試
一個所有Python項目維護者都需要面對的問題是兼容性。如果你的目標是同時支持Python 2.x和Python 3.x（如果你目前只支持Python 2.x，應該這樣做），實際中你如何確保你的項目支持你所說的所有版本呢？畢竟，當你運行測試時，你只使用特定的版本環境來運行測試，它很可能在Python2.7.5中運行良好但在Python 2.6和3.3出現問題。
幸運的是有一個工具致力于解決這個問題。tox提供了“Python的標準化測試”，它不僅僅是在多個版本環境中運行你的測試。它創造了一個完整的沙箱環境，在這個環境中你的包和需求被安裝和測試。如果你做了更改在測試時沒有異常，但意外地影響了安裝，使用Tox你會發現這類問題。
通過一個.ini文件配置tox：tox.ini。它是一個很容易配置的文件，下面是從tox文檔中摘出來的一個最小化配置的tox.ini：
通過設置envlist為py26和py27，tox知道需要在這兩種版本環境下運行測試。tox大約支持十幾個“默認”的環境沙箱，包括jython和pypy。tox這個強大的工具使用不同的版本進行測試，在不支持多版本時可配置警示。
deps是你的包依賴列表。你甚至可以讓tox從PyPI地址安裝所有或一些你依賴包。顯然，相當多的想法和工作已融入了項目。
實際在你的所有環境下運行測試現在只需要四個按鍵：
一個更復雜的設置
我的書——“寫地道的Python”，實際上寫的是一系列的Python模塊和代碼。這樣做是為了確保所有的示例代碼按預期工作。作為我的構建過程的一部分，我運行tox來確保任何新的語法代碼能正常運行。我偶爾也看看我的測試覆蓋率，以確保沒有語法在測試中被無意跳過。因此，我的tox.ini比上面的復雜一些，一起來看一看：
這個配置文件依舊比較簡單。而結果呢？
（我從輸出列表里截取了一部分）。如果想看我的測試對一個環境的覆蓋率，只需運行：
結果很可怕啊。
setuptools整合
tox可以和setuptools整合，這樣python的setup.py測試可以運行你的tox測試。將下面的代碼段放到你的setup.py文件里，這段代碼是直接從tox的文檔里拿來的：
現在Python的setup.py測試將下載tox并運行它。真的很酷并且很節省時間。
Sphinx文檔生成器
Sphinx是由pocoo團隊開發的工具[@Lesus 注：pocoo團隊開發了很多優秀的產品：如Flask, Jinja2等等]。它已經用來生成Python官方文檔和大多數流行的Python包的文檔。它以更容易的方式從Python代碼中自動產生Python文檔。
使用它完成工作
Sphinx不用了解Python程序以及怎樣從它們中提取出來。它只能翻譯reStructuredText文件，也就意味著你的代碼文檔的reStructuredText譯文需要讓Sphinx知道才能工作，但是管理維護所有的.py文件[至少是函數和類的部分]的reStructuredText譯文顯然是不可行的。
幸運的是，Sphinx有一個類似javadoc的擴展，叫做autodoc,可以用來從你的代碼文檔中萃取出reStructuredText。為了能夠充分利用Sphinx和autodoc的能力，你需要以一種特別的方式格式化你的文檔。特別是，你需要使用Sphinx的Python指令時。這里就是使用reStructuredText指令來為一個函數生成文檔，使輸出結果的HTML文檔更漂亮：
文檔需要花費一點功夫，但是為了你的使用者，這個付出是值得的。好吧，好的文檔使一個可用的項目去其糟粕。
Sphinx的autodoc擴展讓我們可以使用很多指令，而這些指令可以自動的從你文檔中生成文檔。
安裝
確認將Sphinx安裝在你的virtualenv內，因為文檔在項目里也是按版本來的。Sphinx不同的版本可能會產生不同的HTML輸出。通過將其安裝在你的virtualenv內，你可以以受控的方式升級你的文檔。
我們要保持我們的文檔在docs文件夾，將文檔生成到docs/generated文件夾。在項目的根目錄運行以下命令將根據你的文檔字符自動重構文本文檔：
這將產生一個包含多個文檔文件的docs文件夾。此外，它創建了一個叫conf.py的文件，它將負責你的文檔配置。你還會發現一個Makefile，方便使用一個命令（生成html）構建HTML文檔。
在你最終生成文檔之前，確保你已經在本地安裝了相應的包（盡管可以使用pip，但python setup.py develop是最簡單的保持更新的方法），否則sphinx-apidoc無法找到你的包。
配置:conf.py
conf.py文件創建用來控制產生的文檔的各個方面。它自己會很好生成文檔，所以我只簡單地觸及兩點。
版本和發布
首先，確保你的版本和發布版本號保持最新。這些數字會作為生成的文檔的一部分顯示，所以你不希望它們遠離了實際值。
保持你的版本最新的最簡單方式就是在你的文檔和setup.py文件中都從你的包的__version__屬性讀取。我從Flask的conf.py借用過來配置sandman的conf.py：
這就是說，為了讓文檔產生正確的版本號，你只需在你的項目的虛擬環境中簡單的需要運行$python setup.py develop即可?，F在你只需擔心保持__version__為最新，因為setup.py會使用它。
html_theme
考慮到更改default到html_theme，我更喜歡原生態的東西，顯然這是一個個人喜好的問題。我之所以提出這個問題是因為Python官方文檔在Python 2和Python 3將默認主題更改為Pydoc主題（后者的主題是一個自定義主題僅在CPython源代碼中可用）。對一些人來說，默認的主題使一個項目看起來“老”一些。
PyPI
PyPI，Python包索引（以前被稱為“Cheeseshop”）是一個公開可用的Python包中央數據庫。PyPI是你的項目發布的地方。一旦你的包（及其相關的元數據）上傳到PyPI，別人通過pip或easy_instal可以下載并安裝它。這一點得強調一下：即使你的項目托管在GitHub，直到被上傳到PyPI后你的項目才是有用的。當然，有些人可以復制你的git庫任何直接手工安裝它，但更多的人想使用pip來安裝它。
最后的一步
如果你已經完成了所有的前面部分中的步驟，你可能急著想把你的包上傳到PyPI，供其他人使用！
先別急著做上述事情，在分發你的包之前，有一個叫做cheesecake的有用的工具有助于運行最后一步。它分析你的包并指定一個分類的數字分數。它衡量你的包在打包、安裝、代碼質量以及文檔的數量和質量方面是否容易/正確。
除了作粗略衡量的“準備”，cheesecake在完整性檢查方面很優秀。你會很快看到你的setup.py文件是否有錯或者有沒有忘記為一個文件制作文檔。我建議在上傳每個項目到PyPI之前運行一下它，而不僅只是第一個。
初始化上傳
現在，你已經確定了你的代碼不是垃圾和當人們安裝它時不會崩潰，讓我們把你的包放到PyPI上吧！你將會通過setuptools和setup.py腳本交互。如果這是第一次上傳到PyPI，你將首先注冊它：
注意：如果你還沒有一個免費的PyPI賬戶，你將需要現在去注冊一個，才能注冊這個包[@Lesus 注：注冊之后還需要到郵箱去驗證才行]。在你已使用了上面注冊之后，你就可以創建發布包和上傳到PyPI了:
上面這個命令建立一個源碼發布版(sdist)，然后上傳到PyPI.如果你的包不是純粹的Python（也就是說，你有二進制需要編譯進去），你就需要發布一個二進制版，請看setuptools文檔，了解更多。
發布及版本號
PyPI使用發行版本模型來確定你軟件包的哪個版本是默認可用的。初次上傳后，為使你軟件包的每次更新后在PyPI可用，你需要指定一個新版本號創建一個發布。版本號管理是一個相當復雜的課題，PEP有專門的內容：PEP 440——版本識別和依賴指定。我建議參照PEP 400指南（明顯地），但如果你選擇使用不同版本的方案，在setup.py中使用的版本比目前PyPI中的版本“高”，這樣PyPI才會認為這是一個新版本。
工作流
將你的第一個發布版本上傳到PyPI后，基本的工作流程如下：
用戶希望你保持足夠的更新頻率以修復bug。你要管理好你的版本號，不要“過于頻繁”的發布。記住：你的用戶不會手工維護他們每個安裝模塊的不同的版本。
使用TravisCI持續集成
持續集成是指一個項目中所有變化不斷整合的過程（不是周期性的批量更新）。就我們而言，這意味每次我們GitHub提交時，我們通過測試運行來發現是否有什么異常，正如你想象的，這是一個非常有價值的實踐。不要有“忘記運行測試”的提交。如果你的提交通不過測試，你將收到一封電子郵件被告知。
TravisCI是一種使GitHub項目持續集成更容易的服務。如果你還沒有賬號到這看一下注冊一個，完成這些之后，在我們進入CI之前我們先需要創建一個簡單的文件。
通過.travis.yml配置
在TravisCI上的不同項目通過一個.travis.yml文件來配置，這個文件在項目的根目錄。簡要地說，我們需要告訴Travis：
這些都是很直接的東西。下面是sandman.travis.yml的內容：
在列出語言和版本后，我們告訴Travis如何安裝我們的包。在install這行，確認包含下面這行：
這是pip安裝我們項目的要求（如果有必要的話使用PyPI鏡像站點）。另外的兩行內容是sandman特有的。它使用一個額外的服務（coveralls.io）來連續監測測試用例的覆蓋率，這不是所有項目都需要的。
script：列出能運行該項目測試的命令。與上面一樣，sandman還需要做一些額外的工作。你的項目需要的只有Python的setup.py測試，after_success部分也可以一塊刪掉。
一旦你提交了這個文件并在TravisCI中激活了你的項目的，push到GitHub。一會兒后，你會看到一個基于你最近提交的編譯結束結果。如果成功了，你的編譯呈現“綠色”和并且狀態頁會顯示編譯通過。你可以看到你項目在任何時間的編譯歷史。這對對人開發特別有用，在歷史頁可以看到特定開發者出錯和編譯的頻率…
你還會收到一封通知你編譯成功的電子郵件。當然你也可以設置只有在出錯或錯誤被修復時才有郵件通知，但編譯輸出結果相同時也不會發送。這是非常有用的，你在不必被無用的“編譯通過！”郵件淹沒的同時在發生改變仍會收到警示。
用ReadTheDocs做持續文檔集成
盡管PyPI有一個官方文檔站點（pythonhosted.org），但是ReadTheDocs提供了一個更好的體驗。為什么？ReadTheDocs有針對GitHub非常棒的集成。當你注冊ReadTheDocs的時候，你就會看到你的所有GitHub 代碼庫。選擇合適的代碼庫，做一些小幅的配置，那么你的文檔就會在你每次提交到GitHub之后自動重新生成。
配置你的項目應該是一個很直觀的事情。只有一些事需要記住，盡管，這里有一個配置字段的列表，對應的值可能不一定是你直接用得上的：
DRY 不要重復你自己
現在你已經完成了對于一個現存代碼基礎的所有艱難的開源工作，你可能不會想在開始一個新項目的時候把這些事重來一遍。幸運的是，你并不需要這么做。有Andrey Roy的Cookiecutter工具（我連接到了Python版本，盡管還有一些不同語言的版本在the main repo)）
Cookiecutter是一個命令行工具能夠自動執行新建項目的一些步驟來做這篇文章里提到的一些事情。 Daniel Greenfeld (@pydanny )寫了一篇很好的關于它的博客并且提到了如何與這篇文章里提到的實踐聯系上。你可以從這里看看這篇文章： Cookiecutter: Project Templates Made Easy .
結論
我們已經介紹了所有用來開源一個Python包的命令，工具和服務。當然，你可以直接把它扔到GitHub上并且說“自己安裝它”，但是沒人會這么做。并且你僅僅是開發源代碼并不算是真正的開源軟件。
另外，你可能不會為你的項目吸引外部貢獻者。通過這里列出的方法來設立你的項目，你就已經創建了一個容易維護的Python包并且會鼓勵大家來使用和貢獻代碼。而這，就是開源軟件的真正精神，不是嗎？
