經過demo學習OpenStack開發所需的基礎知識 -- 軟件包管理

時間  2019-12-12
標籤 經過 demo 學習 openstack 開發 所需 基礎 知識 軟件包 管理 简体版
原文   原文鏈接

爲何寫這個系列

OpenStack是目前我所知的最大最複雜的基於Python項目。整個OpenStack項目包含了數十個主要的子項目，每一個子項目所用到的庫也不盡相同。所以，對於Python初學者和未接觸過OpenStack項目的人來講，入門的難度至關大。html

幸運的是，OpenStack中的項目有不少共同點。好比，它們有相同的代碼庫結構，都儘量是用一樣的庫，配置文件和單元測試的規範也都幾乎同樣。所以，經過學習這些共通的部分，咱們就能夠快速掌握多個OpenStack項目。可是，萬事開頭難，學習這些基礎知識老是痛苦的。不過，學習的難點並不在於這些知識點自己有多難理解，而是這些基礎知識的應用場景和應用效果對初學者來講都是模糊的。這個系列文章的目的就是幫助有須要的人瞭解OpenStack中一些常見的知識點。理解過程就是經過動手作一個web application demo來實現的。python

這個系列文章會涉及到如下的知識點：git

  • 包管理和pbrweb

  • WSGI, RESTful Service和Pecan框架sql

  • eventletjson

  • SQLAlchymyapi

  • 單元測試服務器

下面的知識點是不會專門講的，若是有遇到不會的請自學：babel

  • gitapp

軟件包管理

軟件包管理是每一個OpenStack項目的基礎，其目的是用來將項目代碼打包成源碼包或者二進制包進行分發。一個項目的代碼可能會被打包放到PyPI上，這樣你能夠經過pip命令安裝這個包；也可能會被打包放到項目的軟件倉庫裏，這樣你能夠經過apt-get install或者yum install來安裝這個軟件包。

不幸的是，Python在軟件包管理十分混亂，至少歷史上十分混亂。緣由有兩個：一是標準庫提供的軟件包管理功能十分弱，二是官方沒有提供統一的軟件包管理標準。對於這個領域，我曾經也是混亂的，只知道使用easy_install和pip來安裝軟件包。不過自從看了The Hacker's Guide to Python（《Python高手之路》）以後，算是知道點前因後果。

軟件打包工具的歷史

這裏我會講一下我知道的Python的軟件打包工具的歷史，咱們按照歷史順序來敘述。

distutils (before 2000)

disutils自從1998年起就是Python標準庫的一部分了，不過它在2000年就中止了開發。disutils是最先的Python打包工具和標準，也奠基了對Python軟件進行打包的一個基本工做方式：使用setup.py文件。來看一個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='author_name@example.com'
      url='http://example.com',
      packages=['webdemo'])

setup.py文件是放在項目根目錄下的：

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

而後你就可使用命令python setup.py build來編譯包，可使用python setup.py install來安裝這個項目。若是須要幫助，能夠經過python setup.py --help-commands來查看支持的命令。

setuptools

disutils中止開發後，setuptools成了繼任者。setuptools提供了不少高級功能，包括自動依賴處理、Egg分發格式以及easy_install命令。setuptools的使用方式和disutils差很少，也是以一個setup函數做爲入口，只不過該函數來自於setuptools模塊，並且支持更多的參數，好比classifiers, setup_requires等，參數更多意味着功能更多。

後來有一段時間setuptools項目發展開始變得緩慢了，就有人從setuptools項目建立了distribute項目。distribute開始支持Python 3等新特性。不過一段時間後，distribute項目又和setuptools項目合併了（2013年3月）。所以，如今已經不存在distribute項目了。

到目前爲止，setuptools仍是使用最多的打包工具，並且開發很活躍，2015年6月剛剛發佈了18.0版本。setuptools項目的文檔在：http://pythonhosted.org/setuptools/。OpenStack目前也是使用setuptools庫來執行打包操做，咱們下面會詳細點介紹setuptools工具。

disutils2

在setuptools項目發展的過程當中，有一個叫disutils2的項目也在並行開發中，其目的是全面取代Python標準庫中的distutils。disutils2的最大改進是將setup函數的參數單獨放到一個setup.cfg的文件中（這些成爲包的元數據）。不夠disutils2這個項目缺點不少，並且沒有功能上還不如setuptools項目，因此在2012年的時候，這個項目被廢棄了。

distlib

這個是一個新的打包工具，目標也是取代disutils。不過這個項目的開發進展也不快，到2015年才發佈了0.2.0版本。目前還未能併入到Python的標準庫中。不過能夠保持關注。項目文檔地址：https://readthedocs.org/projects/distlib/

在OpenStack中使用打包工具

前面已經提到了，OpenStack也是使用setuptools工具來進行打包，不過爲了知足OpenStack項目的需求，引入了一個輔助工具pbr來配合setuptools完成打包工做。

pbr (Python Build Reasonableness)

pbr是一個setuptools的擴展工具，被開發出來的主要目的是爲了方便使用setuptools，其項目文檔地址也在OpenStack官網內：http://docs.openstack.org/developer/pbr/。

先說一下pbr如何使用：

import setuptools

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

按照上面的方式就能夠配置setuptools工具使用pbr來協助完成打包工做。這裏的setup_requires參數意思是setup函數在執行以前須要依賴的包的列表。這裏的依賴的包的功能能夠理解爲生成setup的實際參數。你能夠看到，當使用pbr的時候，setup函數只有兩個參數，然而實際上setuptools.setup函數其實是disutils.core.setup函數，會接收任何參數，這些參數能夠經過在調用時指定，也能夠經過所依賴的擴展來生成（好比pbr）。

那麼OpenStack社區爲啥要開發pbr呢？由於setuptools庫使用起來仍是有點麻煩，參數太多，並且直接經過指定setup函數的參數的方法實在太不方便了。pbr就是爲了方便而生的，它帶了了以下的改進：

  1. 使用setup.cfg文件來提供包的元數據。這個是從disutils2學來的。

  2. 基於requirements.txt文件來實現自動依賴安裝。requirements.txt文件中包含了一個項目所要依賴的庫，這個文件的格式是和pip兼容的。

  3. 利用Sphinx實現文檔自動化。

  4. 基於git history自動生成AUTHORS和ChangeLog文件。

  5. 針對git自動建立文件列表。

  6. 基於git tags的版本號管理。

pbr的版本推導

這裏重點說明一下基於git tag的版本號管理這個功能。當使用pbr的時候，版本號有兩種方式：postversioning和preversioning，postversioning是默認方式。要是用preversioning的方式，則須要設置setup.cfg文件中的*metadata]段的version字段的值*。不管採用哪一種方式，版本號都是從git的歷史推理獲得的。pbr使用的版本號標準是[Linux/Python Compatible Semantic Versioning 3.0.0，簡單的說就是下面這個標準：

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

  1. MAJOR version when you make incompatible API changes,

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

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

pbr的版本推導按照以下的步驟進行（注意，最終版本號纔是軟件包的版本號）：

  1. 若是設置version的值爲一個給定的版本號，且這個版本號恰好對應一個tag，則這個值就是最終版本號（注意，這裏只有簽名的tag纔有效）。

  2. 若是不是上面狀況，則pbr會找到最近的一個tag，而後爲其MINOR值加1獲得一個比它大的最小版本號（注意，這個還不是最終版本號）。

  3. 而後pbr會從最近的一個tag開始遍歷全部的git commit，並檢查每一個提交的commit message，在commit message中查找Sem-Ver:這樣的行：

  • 若是Sem-Ver的值是bugfix，則會增長版本號中PATCH部分的值。

  • 若是Sem-Ver的值是feature或者deprecation，則會增長版本號中MINOR部分的值。

  • 若是Sem-Ver的值是api-break，則會增長版本號中MAJOR部分的值。

  • 若是Sem-Ver行不存在，則認爲值是bugfix。

  • 若是Sem-Ver的值不在上面列出的範圍內，則會給出警告。

  1. 若是使用的是postversioning的方式，也就是setup.cfg中不指定version的值，則pbr會使用規則3推導出來的值做爲目標版本號（只是目標版本號，不是最終版本號）。

  2. 若是使用的是preversioning的方式，也就是setup.cfg中指定了version的值（並且不符合規則1），則會檢查指定的version是否高於規則3推導出來的版本號，若是沒有，則會拋出異常，若是有，則使用指定的版本號做爲目標版本號。

  3. 在獲得目標版本號以後，開始計算開發版本號。開發版本號的形式以下：MAJOR.MINOR.PATCH.devN。這裏要計算的是devN中的N。這個值等於從最近的git tag開始的提交數量。計算完開發版本號以後，就獲得了最終版本號。

總的來講，從上面的規則計算出來的版本號只有兩種形式，一種是發佈版本號（對應到某個tag），另外一種是開發版本號。注意：pbr要求tag都是要簽名的，也就是打tag時要使用git tag -a -s X.Y.Z的形式。

setup.cfg和requirements.txt

setup.cfg

因爲OpenStack項目都使用了setuptools和pbr來執行打包工做，所以項目的元數據都放在setup.cfg文件中。咱們以keystone項目的setup.cfg文件爲例來講明這個文件裏通常會包含什麼內容。如下是寫這篇文章時最新的keystone項目的setup.cfg文件的內容（以#開頭的是我加的註釋）：

[metadata]  # 元數據段
name = keystone  # 軟件包名稱
version = 8.0.0  # 軟件包版本號，還能夠指定preversoining, postversioning等值，具體的做用看pbr的文檔。
summary = OpenStack Identity  # 簡介
description-file =  # 指定README文件
    README.rst
author = OpenStack  # 做者
author-email = openstack-dev@lists.openstack.org  # 做者郵件
home-page = http://www.openstack.org/  # 主頁
classifier =  # 包的分類，下面具體說
    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相關信息
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]  # 指定入口點
console_scripts =  # 指定要生成的可執行文件
    keystone-all = keystone.cmd.all:main
    keystone-manage = keystone.cmd.manage:main

# 下面是其餘entry_points內容，主要用於指定不一樣功能的擴展，和打包無關。
...

(上面有些未註釋的部分我目前還不太清楚，後續補充，能夠先參考PEP301)

這裏說說一下classifier這個參數。這個參數是用來指定一個軟件包的分類、許可證、容許運行的操做系統、容許運行的Python的版本的信息。這些信息是在一個叫trove的項目。關於Python和trove的關係，請參考http://stackoverflow.com/questions/9094220/trove-classifiers-definition。

你能夠在PyPI上找到完整的classifier值列表，地址是：https://pypi.python.org/pypi?%3Aaction=list_classifiers。另外，你也能夠經過setuptools的命令來獲取這個列表，在項目根目錄下執行：python setup.py register --list-classifiers。

requirements.txt

這個文件指定了一個項目依賴的包有哪些，而且支出了依賴的包的版本需求，能夠看看keystone項目的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的軟件包一開始是沒有官方的標準分發格式的。好比Java有jar包或者war包做爲分發格式，Python則什麼都沒有。後來不一樣的工具都開始引入一些比較通用的歸檔格式。好比，setuptools引入了Egg格式。可是，這些都不是官方支持的，存在元數據和包結構彼此不兼容的問題。所以，爲了解決這個問題，PEP 427定義了新的分發包標準，名爲Wheel。目前pip和setuptools工具都支持Wheel格式。這裏咱們簡單總結一下經常使用的分發格式：

  • tar.gz格式：這個就是標準壓縮格式，裏面包含了項目元數據和代碼，可使用python setup.py sdist命令生成。

  • .egg格式：這個本質上也是一個壓縮文件，只是擴展名換了，裏面也包含了項目元數據以及源代碼。這個格式由setuptools項目引入。能夠經過命令python setup.py bdist_egg命令生成。

  • .whl格式：這個是Wheel包，也是一個壓縮文件，只是擴展名換了，裏面也包含了項目元數據和代碼，還支持免安裝直接運行。whl分發包內的元數據和egg包是有些不一樣的。這個格式是由PEP 427引入的。能夠經過命令python setup.py bdist_wheel生成。

.egg-info和.dist-info目錄

若是你到系統中安裝Python庫的路徑下看看，就能看到不少名稱以.egg-info或者以.dist-info結尾的目錄。這些目錄的內容就是這個庫的元數據，是從庫的分發包中拷貝出來的。其中.egg-info類型的目錄來自於Egg格式的分發包，.dist-info類型的目錄來自於Wheel格式的分發包。

軟件包的安裝

安裝工具

上面已經提到了，setuptools項目提供了一個軟件包安裝工具*esay_install。easy_install支持從軟件歸檔文件中或者從PyPI上安裝軟件包，不過這個工具並很差用，好比缺乏卸載功能等，所以並不流行，如今更多的都是使用pip工具。

pip項目提供了很好的軟件包安裝方式，而且已經被包含到Python 3.4中，能夠從PyPI、tarball或者Wheel歸檔中安裝和卸載軟件按包。關於pip常見的用法，這裏就不贅述了(pip install, pip uninstall, pip search, ...)。

安裝路徑

軟件包的安裝路徑依賴於操做系統、Python版本和安裝方式。

  • 在Debian系的系統上（好比Ubuntu）

    • 使用apt-get install從系統軟件源安裝

      • 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系的系統上

    • 使用yum install命令安裝

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

以開發模式安裝

pip的安裝命令可使用-e選項，用來從本地代碼目錄或者版本庫URL來安裝一個開發版本的庫。採用這種方式的時候，在安裝目錄下只會建立一個包含軟件包信息的文件，真正的代碼不會安裝到系統目錄下。

webdemo的打包管理

學習過包管理相關的知識後，咱們就要以OpenStack的方法來建立一個咱們本身的項目。這個項目的名稱是webdemo，就是一個簡單的web服務器。這個項目會貫穿這個系列文章。在本文中，咱們首先要建立webdemo的項目框架並添加軟件包管理相關的內容。

項目目錄結構

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

1 directory, 6 files

這個是一個最簡單的Python項目目錄：

  • 源代碼放在子目錄webdemo/下

  • 而後包含了軟件包管理的所需的文件：setup.py, setup.cfg, requirements.txt

  • LICENSE和README

軟件包管理相關

首先是setup.py，就是這麼簡單：

#!/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 = author@example.com
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 =

只包含最基本的信息。接下來是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庫。源代碼目錄下如今只有一個空的__init__.py文件。咱們已經搭建好了這個最簡單的項目框架了。首先，咱們要把這些代碼提交到git庫，而後打上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命令來生成一個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

驗證成功，在dist/目錄下生成了一個0.0.1版本的源碼歸檔，同時生成了以下的文件和目錄：AUTHORS, ChangeLog, webdemo.egg-info。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程