Ansible源码分析【第二篇】： Ansible源码分析之相关内容讲解

Tox标准化测试（tox.ini）

Tox简介

　　一个所有Python项目维护者都需要面对的问题是兼容性。如果你的目标是同时支持Python 2.x和Python 3.x（如果你目前只支持Python 2.x，应该这样做），实际中你如何确保你的项目支持你所说的所有版本呢？毕竟，当你运行测试时，你只使用特定的版本环境来运行测试，它很可能在 Python2.7.5中运行良好但在Python 2.6和3.3出现问题。
　　幸运的是有一个工具致力于解决这个问题。tox提供了“Python的标准化测试”，它不仅仅是在多个版本环境中运行你的测试。它创造了一个完整的沙箱环境，在这个环境中你的包和需求被安装和测试。如果你做了更改在测试时没有异常，但意外地影响了安装，使用Tox你会发现这类问题。

Tox官网：https://testrun.org/tox/latest/

通过一个.ini文件配置tox：tox.ini。它是一个很容易配置的文件，本例就是要Ansible的tox.ini配置进行讲解。

# cat ansible-2.1.0.0-0.1.rc1/tox.ini
[tox]
envlist = py26,py27,py34,py35               # 告诉tox需要在这几种版本环境下运行测试

[testenv:py34]
deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt    # py34环境下的包依赖列表

[testenv:py35]
deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt    

[testenv]
deps = -r{toxinidir}/test/utils/tox/requirements.txt
whitelist_externals = make
commands =
    python --version
    py26: python -m compileall -fq -x 'test|samples|contrib/inventory/vagrant.py' lib test contrib
    py27: python -m compileall -fq -x 'test|samples' lib test contrib
    py34: python -m compileall -fq -x 'lib/ansible/module_utils|lib/ansible/modules' lib test contrib
    py35: python -m compileall -fq -x 'lib/ansible/module_utils|lib/ansible/modules' lib test contrib
    make tests


[flake8]
# These are things that the devs don't agree make the code more readable
# E128 continuation line under-indented for visual indent
# E201 whitespace after '['
# E202 whitespace before ']'
# E203 whitespace before ','
# E221 multiple spaces before operator
# E225 missing whitespace around operator
# E226 missing whitespace around arithmetic operator
# E231 missing whitespace after ','
# E241 multiple spaces after ','
# E251 unexpected spaces around keyword / parameter equals
ignore = E128,E201,E202,E203,E221,E225,E226,E231,E241,E251
# not all the devs believe in 80 column line length
max-line-length = 160
# Not going to worry about style in the test suite
exclude = tests/*

注：

依赖文件位置及内容

C:\Users\Administrator\Desktop\ansible-2.1.0.0-0.1.rc1\ansible-2.1.0.0-0.1.rc1\test\utils\tox\requirements.txt
#
# Test requirements
#

nose
mock >= 1.0.1, < 1.1
passlib
coverage
coveralls
unittest2
redis
python-memcached
python-systemd
pycrypto

扩展知识点：

Sphinx文档生成器

Roadmap

产品的中长期规划路线

 

RELEASES.txt

历史版本发版记录

 

README.md

Markdown知识扩展：http://www.kuqin.com/shuoit/20141125/343459.html

readme.md书写：http://www.coderli.com/write-readme-for-your-project/

 

MANIFEST.in

Makefile

 　   Linux 环境下的程序员如果不会使用GNU make来构建和管理自己的工程，应该不能算是一个合格的专业程序员，至少不能称得上是 Unix程序员。在 Linux（unix ）环境下使用GNU 的make工具能够比较容易的构建一个属于你自己的工程，整个工程的编译只需要一个命令就可以完成编译、连接以至于最后的执行。不过这需要我们投入一些时间去完成一个或者多个称之为Makefile 文件的编写。
　　所要完成的Makefile 文件描述了整个工程的编译、连接等规则。其中包括：工程中的哪些源文件需要编译以及如何编译、需要创建那些库文件以及如何创建这些库文件、如何最后产生我们想要的可执行文件。尽管看起来可能是很复杂的事情，但是为工程编写Makefile 的好处是能够使用一行命令来完成“自动化编译”，一旦提供一个（通常对于一个工程来说会是多个）正确的 Makefile。编译整个工程你所要做的唯一的一件事就是在shell 提示符下输入make命令。整个工程完全自动编译，极大提高了效率。
　　make是一个命令工具，它解释Makefile 中的指令（应该说是规则）。在Makefile文件中描述了整个工程所有文件的编译顺序、编译规则。Makefile 有自己的书写格式、关键字、函数。像C 语言有自己的格式、关键字和函数一样。而且在Makefile 中可以使用系统shell所提供的任何命令来完成想要的工作。Makefile（在其它的系统上可能是另外的文件名）在绝大多数的IDE 开发环境中都在使用，已经成为一种工程的编译方法。

 COPYING