摘要：不幸的是，在軟件包管理十分混亂，至少歷史上十分混亂。的最大改進(jìn)是將函數(shù)的參數(shù)多帶帶放到一個(gè)的文件中這些成為包的元數(shù)據(jù)?；诘陌姹咎?hào)管理。的版本推導(dǎo)這里重點(diǎn)說(shuō)明一下基于的版本號(hào)管理這個(gè)功能。開(kāi)發(fā)版本號(hào)的形式如下。

OpenStack是目前我所知的最大最復(fù)雜的基于Python項(xiàng)目。整個(gè)OpenStack項(xiàng)目包含了數(shù)十個(gè)主要的子項(xiàng)目，每個(gè)子項(xiàng)目所用到的庫(kù)也不盡相同。因此，對(duì)于Python初學(xué)者和未接觸過(guò)OpenStack項(xiàng)目的人來(lái)說(shuō)，入門的難度相當(dāng)大。

幸運(yùn)的是，OpenStack中的項(xiàng)目有很多共同點(diǎn)。比如，它們有相同的代碼庫(kù)結(jié)構(gòu)，都盡可能是用同樣的庫(kù)，配置文件和單元測(cè)試的規(guī)范也都幾乎一樣。因此，通過(guò)學(xué)習(xí)這些共通的部分，我們就可以快速掌握多個(gè)OpenStack項(xiàng)目。但是，萬(wàn)事開(kāi)頭難，學(xué)習(xí)這些基礎(chǔ)知識(shí)總是痛苦的。不過(guò)，學(xué)習(xí)的難點(diǎn)并不在于這些知識(shí)點(diǎn)本身有多難理解，而是這些基礎(chǔ)知識(shí)的應(yīng)用場(chǎng)景和應(yīng)用效果對(duì)初學(xué)者來(lái)說(shuō)都是模糊的。這個(gè)系列文章的目的就是幫助有需要的人了解OpenStack中一些常見(jiàn)的知識(shí)點(diǎn)。理解過(guò)程就是通過(guò)動(dòng)手做一個(gè)web application demo來(lái)實(shí)現(xiàn)的。

這個(gè)系列文章會(huì)涉及到以下的知識(shí)點(diǎn)：

包管理和pbr

WSGI, RESTful Service和Pecan框架

eventlet

SQLAlchymy

單元測(cè)試

下面的知識(shí)點(diǎn)是不會(huì)專門講的，如果有遇到不會(huì)的請(qǐng)自學(xué)：

git

軟件包管理是每個(gè)OpenStack項(xiàng)目的基礎(chǔ)，其目的是用來(lái)將項(xiàng)目代碼打包成源碼包或者二進(jìn)制包進(jìn)行分發(fā)。一個(gè)項(xiàng)目的代碼可能會(huì)被打包放到PyPI上，這樣你可以通過(guò)pip命令安裝這個(gè)包；也可能會(huì)被打包放到項(xiàng)目的軟件倉(cāng)庫(kù)里，這樣你可以通過(guò)apt-get install或者yum install來(lái)安裝這個(gè)軟件包。

不幸的是，Python在軟件包管理十分混亂，至少歷史上十分混亂。原因有兩個(gè)：一是標(biāo)準(zhǔn)庫(kù)提供的軟件包管理功能十分弱，二是官方?jīng)]有提供統(tǒng)一的軟件包管理標(biāo)準(zhǔn)。對(duì)于這個(gè)領(lǐng)域，我曾經(jīng)也是混亂的，只知道使用easy_install和pip來(lái)安裝軟件包。不過(guò)自從看了The Hacker"s Guide to Python（《Python高手之路》）之后，算是知道點(diǎn)來(lái)龍去脈。

這里我會(huì)講一下我知道的Python的軟件打包工具的歷史，我們按照歷史順序來(lái)敘述。

disutils自從1998年起就是Python標(biāo)準(zhǔn)庫(kù)的一部分了，不過(guò)它在2000年就停止了開(kāi)發(fā)。disutils是最早的Python打包工具和標(biāo)準(zhǔn)，也奠定了對(duì)Python軟件進(jìn)行打包的一個(gè)基本工作方式：使用setup.py文件。來(lái)看一個(gè)setup.py文件的例子：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from disutils.core import setup

setup(name="webdemo",
      description="A simple web demo.",
      author="author name",
      author_email="[email protected]"
      url="http://example.com",
      packages=["webdemo"])

setup.py文件是放在項(xiàng)目根目錄下的：

? ~/programming/python/webdemo git:(master) ? $ ls
LICENSE  README.md  setup.py  webdemo 

然后你就可以使用命令python setup.py build來(lái)編譯包，可以使用python setup.py install來(lái)安裝這個(gè)項(xiàng)目。如果需要幫助，可以通過(guò)python setup.py --help-commands來(lái)查看支持的命令。

disutils停止開(kāi)發(fā)后，setuptools成了繼任者。setuptools提供了很多高級(jí)功能，包括自動(dòng)依賴處理、Egg分發(fā)格式以及easy_install命令。setuptools的使用方式和disutils差不多，也是以一個(gè)setup函數(shù)作為入口，只不過(guò)該函數(shù)來(lái)自于setuptools模塊，而且支持更多的參數(shù)，比如classifiers, setup_requires等，參數(shù)更多意味著功能更多。

后來(lái)有一段時(shí)間setuptools項(xiàng)目發(fā)展開(kāi)始變得緩慢了，就有人從setuptools項(xiàng)目創(chuàng)建了distribute項(xiàng)目。distribute開(kāi)始支持Python 3等新特性。不過(guò)一段時(shí)間后，distribute項(xiàng)目又和setuptools項(xiàng)目合并了（2013年3月）。因此，現(xiàn)在已經(jīng)不存在distribute項(xiàng)目了。

到目前為止，setuptools還是使用最多的打包工具，而且開(kāi)發(fā)很活躍，2015年6月剛剛發(fā)布了18.0版本。setuptools項(xiàng)目的文檔在：http://pythonhosted.org/setuptools/。OpenStack目前也是使用setuptools庫(kù)來(lái)執(zhí)行打包操作，我們下面會(huì)詳細(xì)點(diǎn)介紹setuptools工具。

在setuptools項(xiàng)目發(fā)展的過(guò)程中，有一個(gè)叫disutils2的項(xiàng)目也在并行開(kāi)發(fā)中，其目的是全面取代Python標(biāo)準(zhǔn)庫(kù)中的distutils。disutils2的最大改進(jìn)是將setup函數(shù)的參數(shù)多帶帶放到一個(gè)setup.cfg的文件中（這些成為包的元數(shù)據(jù)）。不夠disutils2這個(gè)項(xiàng)目缺點(diǎn)很多，而且沒(méi)有功能上還不如setuptools項(xiàng)目，所以在2012年的時(shí)候，這個(gè)項(xiàng)目被廢棄了。

這個(gè)是一個(gè)新的打包工具，目標(biāo)也是取代disutils。不過(guò)這個(gè)項(xiàng)目的開(kāi)發(fā)進(jìn)展也不快，到2015年才發(fā)布了0.2.0版本。目前還未能并入到Python的標(biāo)準(zhǔn)庫(kù)中。不過(guò)可以保持關(guān)注。項(xiàng)目文檔地址：https://readthedocs.org/projects/distlib/

前面已經(jīng)提到了，OpenStack也是使用setuptools工具來(lái)進(jìn)行打包，不過(guò)為了滿足OpenStack項(xiàng)目的需求，引入了一個(gè)輔助工具pbr來(lái)配合setuptools完成打包工作。

pbr是一個(gè)setuptools的擴(kuò)展工具，被開(kāi)發(fā)出來(lái)的主要目的是為了方便使用setuptools，其項(xiàng)目文檔地址也在OpenStack官網(wǎng)內(nèi)：http://docs.openstack.org/developer/pbr/。

先說(shuō)一下pbr如何使用：

import setuptools

setuptools.setup(setup_requires=["pbr"], pbr=True)

按照上面的方式就可以配置setuptools工具使用pbr來(lái)協(xié)助完成打包工作。這里的setup_requires參數(shù)意思是setup函數(shù)在執(zhí)行之前需要依賴的包的列表。這里的依賴的包的功能可以理解為生成setup的實(shí)際參數(shù)。你可以看到，當(dāng)使用pbr的時(shí)候，setup函數(shù)只有兩個(gè)參數(shù)，然而實(shí)際上setuptools.setup函數(shù)實(shí)際上是disutils.core.setup函數(shù)，會(huì)接收任何參數(shù)，這些參數(shù)可以通過(guò)在調(diào)用時(shí)指定，也可以通過(guò)所依賴的擴(kuò)展來(lái)生成（比如pbr）。

那么OpenStack社區(qū)為啥要開(kāi)發(fā)pbr呢？因?yàn)閟etuptools庫(kù)使用起來(lái)還是有點(diǎn)麻煩，參數(shù)太多，而且直接通過(guò)指定setup函數(shù)的參數(shù)的方法實(shí)在太不方便了。pbr就是為了方便而生的，它帶了了如下的改進(jìn)：

使用setup.cfg文件來(lái)提供包的元數(shù)據(jù)。這個(gè)是從disutils2學(xué)來(lái)的。

基于requirements.txt文件來(lái)實(shí)現(xiàn)自動(dòng)依賴安裝。requirements.txt文件中包含了一個(gè)項(xiàng)目所要依賴的庫(kù)，這個(gè)文件的格式是和pip兼容的。

利用Sphinx實(shí)現(xiàn)文檔自動(dòng)化。

基于git history自動(dòng)生成AUTHORS和ChangeLog文件。

針對(duì)git自動(dòng)創(chuàng)建文件列表。

基于git tags的版本號(hào)管理。

這里重點(diǎn)說(shuō)明一下基于git tag的版本號(hào)管理這個(gè)功能。當(dāng)使用pbr的時(shí)候，版本號(hào)有兩種方式：postversioning和preversioning，postversioning是默認(rèn)方式。要是用preversioning的方式，則需要設(shè)置setup.cfg文件中的*metadata]段的version字段的值*。無(wú)論采用哪種方式，版本號(hào)都是從git的歷史推理得到的。pbr使用的版本號(hào)標(biāo)準(zhǔn)是[Linux/Python Compatible Semantic Versioning 3.0.0，簡(jiǎn)單的說(shuō)就是下面這個(gè)標(biāo)準(zhǔn)：

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner,

and PATCH version when you make backwards-compatible bug fixes.

pbr的版本推導(dǎo)按照如下的步驟進(jìn)行（注意，最終版本號(hào)才是軟件包的版本號(hào)）：

如果設(shè)置version的值為一個(gè)給定的版本號(hào)，且這個(gè)版本號(hào)剛好對(duì)應(yīng)一個(gè)tag，則這個(gè)值就是最終版本號(hào)（注意，這里只有簽名的tag才有效）。

如果不是上面情況，則pbr會(huì)找到最近的一個(gè)tag，然后為其MINOR值加1得到一個(gè)比它大的最小版本號(hào)（注意，這個(gè)還不是最終版本號(hào)）。

然后pbr會(huì)從最近的一個(gè)tag開(kāi)始遍歷所有的git commit，并檢查每個(gè)提交的commit message，在commit message中查找Sem-Ver:這樣的行：

如果Sem-Ver的值是bugfix，則會(huì)增加版本號(hào)中PATCH部分的值。

如果Sem-Ver的值是feature或者deprecation，則會(huì)增加版本號(hào)中MINOR部分的值。

如果Sem-Ver的值是api-break，則會(huì)增加版本號(hào)中MAJOR部分的值。

如果Sem-Ver行不存在，則認(rèn)為值是bugfix。

如果Sem-Ver的值不在上面列出的范圍內(nèi)，則會(huì)給出警告。

如果使用的是postversioning的方式，也就是setup.cfg中不指定version的值，則pbr會(huì)使用規(guī)則3推導(dǎo)出來(lái)的值作為目標(biāo)版本號(hào)（只是目標(biāo)版本號(hào)，不是最終版本號(hào)）。

如果使用的是preversioning的方式，也就是setup.cfg中指定了version的值（而且不符合規(guī)則1），則會(huì)檢查指定的version是否高于規(guī)則3推導(dǎo)出來(lái)的版本號(hào)，如果沒(méi)有，則會(huì)拋出異常，如果有，則使用指定的版本號(hào)作為目標(biāo)版本號(hào)。

在得到目標(biāo)版本號(hào)之后，開(kāi)始計(jì)算開(kāi)發(fā)版本號(hào)。開(kāi)發(fā)版本號(hào)的形式如下：MAJOR.MINOR.PATCH.devN。這里要計(jì)算的是devN中的N。這個(gè)值等于從最近的git tag開(kāi)始的提交數(shù)量。計(jì)算完開(kāi)發(fā)版本號(hào)之后，就得到了最終版本號(hào)。

總的來(lái)說(shuō)，從上面的規(guī)則計(jì)算出來(lái)的版本號(hào)只有兩種形式，一種是發(fā)布版本號(hào)（對(duì)應(yīng)到某個(gè)tag），另一種是開(kāi)發(fā)版本號(hào)。注意：pbr要求tag都是要簽名的，也就是打tag時(shí)要使用git tag -a -s X.Y.Z的形式。

由于OpenStack項(xiàng)目都使用了setuptools和pbr來(lái)執(zhí)行打包工作，因此項(xiàng)目的元數(shù)據(jù)都放在setup.cfg文件中。我們以keystone項(xiàng)目的setup.cfg文件為例來(lái)說(shuō)明這個(gè)文件里一般會(huì)包含什么內(nèi)容。以下是寫這篇文章時(shí)最新的keystone項(xiàng)目的setup.cfg文件的內(nèi)容（以#開(kāi)頭的是我加的注釋）：

[metadata]  # 元數(shù)據(jù)段
name = keystone  # 軟件包名稱
version = 8.0.0  # 軟件包版本號(hào)，還可以指定preversoining, postversioning等值，具體的作用看pbr的文檔。
summary = OpenStack Identity  # 簡(jiǎn)介
description-file =  # 指定README文件
    README.rst
author = OpenStack  # 作者
author-email = [email protected]  # 作者郵件
home-page = http://www.openstack.org/  # 主頁(yè)
classifier =  # 包的分類，下面具體說(shuō)
    Environment :: OpenStack
    Intended Audience :: Information Technology
    Intended Audience :: System Administrators
    License :: OSI Approved :: Apache Software License
    Operating System :: POSIX :: Linux
    Programming Language :: Python
    Programming Language :: Python :: 2
    Programming Language :: Python :: 2.7

[files]  # 文件段
packages =  # 包名稱
    keystone

[global]  # 全局段
setup-hooks =  # 指定安裝hook
    pbr.hooks.setup_hook


[egg_info]  # 指定egg信息
tag_build =
tag_date = 0
tag_svn_revision = 0

[build_sphinx]  # 文檔build相關(guān)信息
all_files = 1
build-dir = doc/build
source-dir = doc/source

[compile_catalog]
directory = keystone/locale
domain = keystone

[update_catalog]
domain = keystone
output_dir = keystone/locale
input_file = keystone/locale/keystone.pot

[extract_messages]
keywords = _ gettext ngettext l_ lazy_gettext
mapping_file = babel.cfg
output_file = keystone/locale/keystone.pot
copyright_holder = OpenStack Foundation
msgid_bugs_address = https://bugs.launchpad.net/keystone

# NOTE(dstanek): Uncomment the [pbr] section below and remove the ext.apidoc
# Sphinx extension when https://launchpad.net/bugs/1260495 is fixed.
[pbr]  # pbr本身的配置
warnerrors = True
autodoc_tree_index_modules = True

[entry_points]  # 指定入口點(diǎn)
console_scripts =  # 指定要生成的可執(zhí)行文件
    keystone-all = keystone.cmd.all:main
    keystone-manage = keystone.cmd.manage:main

# 下面是其他entry_points內(nèi)容，主要用于指定不同功能的擴(kuò)展，和打包無(wú)關(guān)。
...

(上面有些未注釋的部分我目前還不太清楚，后續(xù)補(bǔ)充，可以先參考PEP301)

這里說(shuō)說(shuō)一下classifier這個(gè)參數(shù)。這個(gè)參數(shù)是用來(lái)指定一個(gè)軟件包的分類、許可證、允許運(yùn)行的操作系統(tǒng)、允許運(yùn)行的Python的版本的信息。這些信息是在一個(gè)叫trove的項(xiàng)目。關(guān)于Python和trove的關(guān)系，請(qǐng)參考http://stackoverflow.com/questions/9094220/trove-classifiers-definition。

你可以在PyPI上找到完整的classifier值列表，地址是：https://pypi.python.org/pypi?%3Aaction=list_classifiers。另外，你也可以通過(guò)setuptools的命令來(lái)獲取這個(gè)列表，在項(xiàng)目根目錄下執(zhí)行：python setup.py register --list-classifiers。

這個(gè)文件指定了一個(gè)項(xiàng)目依賴的包有哪些，并且支出了依賴的包的版本需求，可以看看keystone項(xiàng)目的requirements.txt：

# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.

pbr<2.0,>=0.11
WebOb>=1.2.3
eventlet>=0.17.4
greenlet>=0.3.2
PasteDeploy>=1.5.0
Paste
Routes!=2.0,>=1.12.3
cryptography>=0.8.2 # Apache-2.0
six>=1.9.0
SQLAlchemy<1.1.0,>=0.9.7
sqlalchemy-migrate>=0.9.6
stevedore>=1.5.0 # Apache-2.0
passlib
python-keystoneclient>=1.6.0
keystonemiddleware>=1.5.0
oslo.concurrency>=2.1.0 # Apache-2.0
oslo.config>=1.11.0 # Apache-2.0
oslo.messaging!=1.12.0,>=1.8.0 # Apache-2.0
oslo.db>=1.10.0 # Apache-2.0
oslo.i18n>=1.5.0 # Apache-2.0
oslo.log>=1.2.0 # Apache-2.0
oslo.middleware!=2.0.0,>=1.2.0 # Apache-2.0
oslo.policy>=0.5.0 # Apache-2.0
oslo.serialization>=1.4.0 # Apache-2.0
oslo.service>=0.1.0 # Apache-2.0
oslo.utils>=1.6.0 # Apache-2.0
oauthlib>=0.6
pysaml2>=2.4.0
dogpile.cache>=0.5.3
jsonschema!=2.5.0,<3.0.0,>=2.0.0
pycadf>=0.8.0
msgpack-python>=0.4.0

Python的軟件包一開(kāi)始是沒(méi)有官方的標(biāo)準(zhǔn)分發(fā)格式的。比如Java有jar包或者war包作為分發(fā)格式，Python則什么都沒(méi)有。后來(lái)不同的工具都開(kāi)始引入一些比較通用的歸檔格式。比如，setuptools引入了Egg格式。但是，這些都不是官方支持的，存在元數(shù)據(jù)和包結(jié)構(gòu)彼此不兼容的問(wèn)題。因此，為了解決這個(gè)問(wèn)題，PEP 427定義了新的分發(fā)包標(biāo)準(zhǔn)，名為Wheel。目前pip和setuptools工具都支持Wheel格式。這里我們簡(jiǎn)單總結(jié)一下常用的分發(fā)格式：

tar.gz格式：這個(gè)就是標(biāo)準(zhǔn)壓縮格式，里面包含了項(xiàng)目元數(shù)據(jù)和代碼，可以使用python setup.py sdist命令生成。

.egg格式：這個(gè)本質(zhì)上也是一個(gè)壓縮文件，只是擴(kuò)展名換了，里面也包含了項(xiàng)目元數(shù)據(jù)以及源代碼。這個(gè)格式由setuptools項(xiàng)目引入?？梢酝ㄟ^(guò)命令python setup.py bdist_egg命令生成。

.whl格式：這個(gè)是Wheel包，也是一個(gè)壓縮文件，只是擴(kuò)展名換了，里面也包含了項(xiàng)目元數(shù)據(jù)和代碼，還支持免安裝直接運(yùn)行。whl分發(fā)包內(nèi)的元數(shù)據(jù)和egg包是有些不同的。這個(gè)格式是由PEP 427引入的。可以通過(guò)命令python setup.py bdist_wheel生成。

如果你到系統(tǒng)中安裝Python庫(kù)的路徑下看看，就能看到很多名稱以.egg-info或者以.dist-info結(jié)尾的目錄。這些目錄的內(nèi)容就是這個(gè)庫(kù)的元數(shù)據(jù)，是從庫(kù)的分發(fā)包中拷貝出來(lái)的。其中.egg-info類型的目錄來(lái)自于Egg格式的分發(fā)包，.dist-info類型的目錄來(lái)自于Wheel格式的分發(fā)包。

上面已經(jīng)提到了，setuptools項(xiàng)目提供了一個(gè)軟件包安裝工具*esay_install。easy_install支持從軟件歸檔文件中或者從PyPI上安裝軟件包，不過(guò)這個(gè)工具并不好用，比如缺少卸載功能等，因此并不流行，現(xiàn)在更多的都是使用pip工具。

pip項(xiàng)目提供了很好的軟件包安裝方式，并且已經(jīng)被包含到Python 3.4中，可以從PyPI、tarball或者Wheel歸檔中安裝和卸載軟件按包。關(guān)于pip常見(jiàn)的用法，這里就不贅述了(pip install, pip uninstall, pip search, ...)。

軟件包的安裝路徑依賴于操作系統(tǒng)、Python版本和安裝方式。

在Debian系的系統(tǒng)上（比如Ubuntu）

使用apt-get install從系統(tǒng)軟件源安裝

Python 2.7: /usr/lib/python2.7/dist-packages

Python 3.4: /usr/lib/python3.4/dist-packages

使用pip install命令安裝

Python 2.7: /usr/local/lib/python2.7/dist-packages

Python 3.4: /usr/local/lib/python3.4/dist-packages

在virtualenv中使用pip install安裝

Python 2.7: lib/python2.7/site-packages

Python 3.4: lib/python3.4/site-packages

在CentOS系的系統(tǒng)上

使用yum install命令安裝

Python 2.7: /usr/lib/python2.7/site-packages

pip的安裝命令可以使用-e選項(xiàng)，用來(lái)從本地代碼目錄或者版本庫(kù)URL來(lái)安裝一個(gè)開(kāi)發(fā)版本的庫(kù)。采用這種方式的時(shí)候，在安裝目錄下只會(huì)創(chuàng)建一個(gè)包含軟件包信息的文件，真正的代碼不會(huì)安裝到系統(tǒng)目錄下。

學(xué)習(xí)過(guò)包管理相關(guān)的知識(shí)后，我們就要以O(shè)penStack的方法來(lái)創(chuàng)建一個(gè)我們自己的項(xiàng)目。這個(gè)項(xiàng)目的名稱是webdemo，就是一個(gè)簡(jiǎn)單的web服務(wù)器。這個(gè)項(xiàng)目會(huì)貫穿這個(gè)系列文章。在本文中，我們首先要?jiǎng)?chuàng)建webdemo的項(xiàng)目框架并添加軟件包管理相關(guān)的內(nèi)容。

? ~/programming/python/webdemo git:(master) ? $ tree .
.
├── LICENSE
├── README.md
├── requirement.txt
├── setup.cfg
├── setup.py
└── webdemo
    └── __init__.py

1 directory, 6 files

這個(gè)是一個(gè)最簡(jiǎn)單的Python項(xiàng)目目錄：

源代碼放在子目錄webdemo/下

然后包含了軟件包管理的所需的文件：setup.py, setup.cfg, requirements.txt

LICENSE和README

首先是setup.py，就是這么簡(jiǎn)單：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import setuptools


# In python < 2.7.4, a lazy loading of package `pbr` will break
# setuptools if some other modules registered functions in `atexit`.
# solution from: http://bugs.python.org/issue15881#msg170215
try:
        import multiprocessing  # noqa
except ImportError:
        pass


setuptools.setup(
    setup_requires=["pbr"], pbr=True)

然后是setup.cfg：

[metadata]
name = webdemo
version = 0.0.1
summary = Web Application Demo
description-file = README.md
author = author
author-email = [email protected]
classifier =
    Environment :: Web Environment
    Intended Audience :: Developers
    Intended Audience :: Education
    License :: OSI Approved :: GNU General Public License v2 (GPLv2)
    Operating System :: POSIX :: Linux
    Programming Language :: Python
    Programming Language :: Python :: 2
    Programming Language :: Python :: 2.7

[global]
setup-hooks =
    pbr.hooks.setup_hook

[files]
packages =
    webdemo

[entry_points]
console_scripts =

只包含最基本的信息。接下來(lái)是requirements.txt文件：

# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.

pbr<2.0,>=0.11

目前只依賴于pbr庫(kù)。源代碼目錄下現(xiàn)在只有一個(gè)空的__init__.py文件。我們已經(jīng)搭建好了這個(gè)最簡(jiǎn)單的項(xiàng)目框架了。首先，我們要把這些代碼提交到git庫(kù)，然后打上tag 0.0.1：

? ~/programming/python/webdemo git:(master) ? $ git log --oneline
697427c Add packaging information
2cbbf4d Initial commit
? ~/programming/python/webdemo git:(master) ? $ git tag -a -s 0.0.1
? ~/programming/python/webdemo git:(master) ? $ git tag
0.0.1

然后就可以使用python setup.py sdist命令來(lái)生成一個(gè)0.0.1版本的源碼歸檔了：

? ~/programming/python/webdemo git:(master) ? $ python setup.py sdist
running sdist
[pbr] Writing ChangeLog
[pbr] Generating ChangeLog
[pbr] Generating AUTHORS
running egg_info
writing pbr to webdemo.egg-info/pbr.json
writing webdemo.egg-info/PKG-INFO
writing top-level names to webdemo.egg-info/top_level.txt
writing dependency_links to webdemo.egg-info/dependency_links.txt
writing entry points to webdemo.egg-info/entry_points.txt
[pbr] Processing SOURCES.txt
[pbr] In git context, generating filelist from git
warning: no previously-included files found matching ".gitreview"
warning: no previously-included files matching "*.pyc" found anywhere in distribution
writing manifest file "webdemo.egg-info/SOURCES.txt"
warning: sdist: standard file not found: should have one of README, README.rst, README.txt

running check
warning: check: missing required meta-data: url

creating webdemo-0.0.1
creating webdemo-0.0.1/webdemo
creating webdemo-0.0.1/webdemo.egg-info
making hard links in webdemo-0.0.1...
hard linking AUTHORS -> webdemo-0.0.1
hard linking ChangeLog -> webdemo-0.0.1
hard linking LICENSE -> webdemo-0.0.1
hard linking README.md -> webdemo-0.0.1
hard linking requirement.txt -> webdemo-0.0.1
hard linking setup.cfg -> webdemo-0.0.1
hard linking setup.py -> webdemo-0.0.1
hard linking webdemo/__init__.py -> webdemo-0.0.1/webdemo
hard linking webdemo.egg-info/PKG-INFO -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/SOURCES.txt -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/dependency_links.txt -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/entry_points.txt -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/not-zip-safe -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/pbr.json -> webdemo-0.0.1/webdemo.egg-info
hard linking webdemo.egg-info/top_level.txt -> webdemo-0.0.1/webdemo.egg-info
copying setup.cfg -> webdemo-0.0.1
Writing webdemo-0.0.1/setup.cfg
Creating tar archive
removing "webdemo-0.0.1" (and everything under it)
? ~/programming/python/webdemo git:(master) ? $ ls dist
webdemo-0.0.1.tar.gz
? ~/programming/python/webdemo git:(master) ? $ ls
AUTHORS  ChangeLog  dist  LICENSE  README.md  requirement.txt  setup.cfg  setup.py  webdemo  webdemo.egg-info

驗(yàn)證成功，在dist/目錄下生成了一個(gè)0.0.1版本的源碼歸檔，同時(shí)生成了如下的文件和目錄：AUTHORS, ChangeLog, webdemo.egg-info。