共计 6728 个字符，预计需要花费 17 分钟才能阅读完成。
Python 历时这么久以来至今还未有一个事实上规范的项目管理及构建工具，以至于造成 Python 我的项目的构造与构建形式形形色色。这或者是体现了 Python 的自在意志。
不像 Java 在经验了最后的手工构建，到半自动化的 Ant, 再到 Maven 根本就是事实上的规范了。其间 Maven 还承受了其余的 Gradle(Android 我的项目主推), SBT(次要是 Scala 我的项目), Ant+Ivy, Buildr 等的挑战，但都很难撼动 Maven 的江湖位置，而且其余的差不多遵循了 Maven 的目录布局。
回到 Python，产生过 pip, pipenv, conda 那样的包管理工具，但对我的项目的目录布局没有任何约定。
对于构建很多还是连续了传统的 Makefile 的形式，再就是加上 setup.py 和 build.py 用程序代码来进行装置与构建。对于我的项目目录布局，有做成我的项目模板的，而后做成工具来利用我的项目模板。
上面大略浏览一下四个工具的应用
- CookieCutter
- PyScaffold
- PyBuilder
- Poetry
CookieCutter 一个经典的 Python 我的项目目录构造
$ pip install cookiecutter
$ cookiecutter gh:audreyr/cookiecutter-pypackage # 以 github 上的 audreyr/cookiecutter-pypackage 为模板，再答复一堆的问题生成一个 Python 我的项目
......
project_name [Python Boilerplate]: sample
......最初由 cookiecutter 生成的我的项目模板是上面的样子：
$ tree sample
sample
├── AUTHORS.rst
├── CONTRIBUTING.rst
├── HISTORY.rst
├── LICENSE
├── MANIFEST.in
├── Makefile
├── README.rst
├── docs
│ ├── Makefile
│ ├── authors.rst
│ ├── conf.py
│ ├── contributing.rst
│ ├── history.rst
│ ├── index.rst
│ ├── installation.rst
│ ├── make.bat
│ ├── readme.rst
│ └── usage.rst
├── requirements_dev.txt
├── sample
│ ├── __init__.py
│ ├── cli.py
│ └── sample.py
├── setup.cfg
├── setup.py
├── tests
│ ├── __init__.py
│ └── test_sample.py
└── tox.ini
3 directories, 26 files这大略是以后比拟风行的目录构造的主体框架，次要元素是：
$ tree sample
sample
├── Makefile
├── README.rst
├── docs
│ └── index.rst
├── requirements.txt
├── sample
│ ├── __init__.py
│ └── sample.py
├── setup.cfg
├── setup.py
└── tests
├── __init__.py
└── test_sample.py我的项目 sample 目录中反复 sample 目录中搁置 Python 源文件，tests 目录中是测试文件，再加一个 docs 目录放文档，README.rst, 其余的用于构建的 setup, setup.cfg 和 Makefile 文件。
这其实是一个很经典的 Python 我的项目构造，接下来的构建就用 make 命令了，输出 make 会看到定义在 Makefile 文件中的指令
$ make
clean remove all build, test, coverage and Python artifacts
clean-build remove build artifacts
clean-pyc remove Python file artifacts
clean-test remove test and coverage artifacts
lint check style
test run tests quickly with the default Python
test-all run tests on every Python version with tox
coverage check code coverage quickly with the default Python
docs generate Sphinx HTML documentation, including API docs
servedocs compile the docs watching for changes
release package and upload a release
dist builds source and wheel package
install install the package to the active Python's site-packages为应用下面的构建过程，须要装置相应的包，如 tox, wheel, coverage, sphinx, flake8, 它们都能够通过 pip 来装置。之后就能够 make test, make coverage, make docs，make dist 等。其中 make docs 能够生成一个很漂亮的 Web 文档。
PyScaffold 创立一个我的项目
PyScaffold 顾名思义，它是一个用来创立 Python 我的项目脚手架的工具，装置和应用：
$ pip install pyscaffold
$ putup sample这样创立了一个 Python 我的项目，目录构造与后面 cookiecutter 所选的模板差不多，只不过它把源文件放在了 src 目录，而非 sample 目录。
$ tree sample
sample
├── AUTHORS.rst
├── CHANGELOG.rst
├── CONTRIBUTING.rst
├── LICENSE.txt
├── README.rst
├── docs
│ ├── Makefile
│ ├── _static
│ ├── authors.rst
│ ├── changelog.rst
│ ├── conf.py
│ ├── contributing.rst
│ ├── index.rst
│ ├── license.rst
│ ├── readme.rst
│ └── requirements.txt
├── pyproject.toml
├── setup.cfg
├── setup.py
├── src
│ └── sample
│ ├── __init__.py
│ └── skeleton.py
├── tests
│ ├── conftest.py
│ └── test_skeleton.py
└── tox.ini整个我的项目的构建就要用 tox 这个工具了。tox 是一个自动化测试和构建工具，它在构建过程中可创立 Python 虚拟环境，这让测试和构建能有一个洁净的环境。tox 应用教程
tox -av 能显示出定义在 tox.ini 中所有的工作：
$ tox -av
default environments:
default -> Invoke pytest to run automated tests
additional environments:
build -> Build the package in isolation according to PEP517, see https://github.com/pypa/build
clean -> Remove old distribution files and temporary build artifacts (./build and ./dist)
docs -> Invoke sphinx-build to build the docs
doctests -> Invoke sphinx-build to run doctests
linkcheck -> Check for broken links in the documentation
publish -> Publish the package you have been developing to a package index server. By default, it uses testpypi. If you really want to publish your package to be publicly accessible in PyPI, use the `-- --repository pypi` option.要执行哪个命令便用 tox -e build, tox -e docs 等,
在我体验 tox 命令过程中，每一步如同都比较慢，应该是创立虚拟机要花些工夫。
PyBuilder
最好再看另一个构建工具 PyBuilder，它所创立出的目录构造很靠近于 Maven, 上面来瞧瞧
$ pip install pybuilder
$ mkdir sample && cd sample # 我的项目目录需手工创立
$ pyb --start-project # 答复一些问题后创立所需的目录和文件完后看下它的目录构造：
$ tree sample
.
├── build.py
├── docs
├── pyproject.toml
├── setup.py
└── src
├── main
│ ├── python
│ └── scripts
└── unittest
└── python构建过程依然是用 pyb 命令，可用 pyb -h 查看帮忙，pyb -t 列出所有的工作, PyBuilder 的工作是以插件的形式退出的，插件配置在 build.py 文件中。
$ pyb -t sample
Tasks found for project "sample":
analyze - Execute analysis plugins.
depends on tasks: prepare run_unit_tests
clean - Cleans the generated output.
compile_sources - Compiles source files that need compilation.
depends on tasks: prepare
coverage - <no description available>
depends on tasks: verify
install - Installs the published project.
depends on tasks: package publish(optional)
package - Packages the application. Package a python application.
depends on tasks: compile_sources run_unit_tests(optional)
prepare - Prepares the project for building. Creates target VEnvs
print_module_path - Print the module path.
print_scripts_path - Print the script path.
publish - Publishes the project.
depends on tasks: package verify(optional) coverage(optional)
run_integration_tests - Runs integration tests on the packaged application.
depends on tasks: package
run_unit_tests - Runs all unit tests. Runs unit tests based on Python's unittest module
depends on tasks: compile_sources
upload - Upload a project to PyPi.
verify - Verifies the project and possibly integration tests.
depends on tasks: run_integration_tests(optional)
$ pyb run_unit_tests samplePyBuilder 也是在构建或测试之前创立虚拟环境, 从 0.12.9 版开始可通过参数 –no-venvs 跳过创立虚拟环境这一步。应用了 –no-venvs 的话 Python 代码将会在运行 pyb 的以后 Python 环境中执行，所需的依赖将要手工装置。
我的项目的依赖也要定义在 build.py 文件中
@init
def set_properties(project):
project.depends_on('boto3', '>=1.18.52')
project.build_depends_on('mock')随后在执行 pyb 创立虚拟环境时就会装置下面的依赖，并在其中运行测试与构建。
Poetry
最初一个 Poetry, 感觉这是一个更为成熟，我的项目活跃度也更高的 Python 构建，它有着更弱小的信赖治理性能，用 poetry add boto3 就能增加依赖，poetry show –tree 显示出依赖树。看下如何装置及创立一个我的项目
$ pip install poetry
$ poetry new sample它创立的我的项目比下面都简略
$ tree sample
sample
├── README.rst
├── pyproject.toml
├── sample
│ └── __init__.py
└── tests
├── __init__.py
└── test_sample.py如果给 poetry new 带上 –src 参数，那么源文件目录 sample 会放在 src 目录下，即 sample/src/sample.
poetry init 会在当前目录中生成 pyproject.toml 文件，目录等的生成需手动实现。
它不关注文档的生成，代码标准的查看，代码覆盖率都没有。它的我的项目配置更集中，全副在 pyproject.toml 文件中，toml 是什么呢？它是一种配置文件的格局 Tom’s Obvious, Minimal Language (https://github.com/toml-lang/…).
pyproject.toml 有些相似 NodeJS 的 package.json 文件，比方 poetry add, poetry install 命令的行
- poetry add boto3 # 往 pyproject.toml 中增加对 boto3 的依赖并装置(add 还能从本地或 git 来装置依赖), 用 –dev 参数是给开发时用的
- poetry install # 将按照 pyproject.toml 文件中定义装置相应的依赖到以后的 Python 虚拟环境中，比方在 <test-venv>/lib/python3.9/site-packages 目录中，装置好模块后也可让测试用例应用
其余次要的
- poetry build # 构建可装置的 *.whl 和 tar.gz 文件
- poetry shell # 会依据定义在 pyproject.toml 文件中的依赖创立并应用虚拟环境
- poetry run pytest # 运行应用 pytest 的测试用例，如 tests/test_sample.py
- poetry run python -m unittest tests/sample_tests.py # 运行 unittest 测试用例
- poetry export –without-hashes –output requirements.txt # 导出 requirements.txt 文件, –dev 导出含 dev 的依赖，或者用 poetry export –without-hashes > requirements.txt
poetry run 能执行任何系统命令，只是它会在它要的虚拟环境中执行。所以能够想见，poetry 的我的项目要生成文档或覆盖率都必须用 poetry run … 命令来反对 sphinx, coverage 或 flake8。
在 sample 目录 (与 pyproject.toml 文件平级) 中创立文件 my_module.py, 内容为
def main():
print('hello poetry')而后在 pyproject.toml 中写上
[tool.poetry.scripts]
my-script="sample.my_module:main"再执行
$ poetry run my-script
就会输入 “hello poetry”。
通过对以上四个工具的意识，我的项目构造的复杂度由 cookiecutter-pyproject -> PyScaffold -> PyBuilder -> Poetry 顺次升高，应用的难度大略也是雷同的程序。
最近整顿了几百 G 的 Python 学习材料，蕴含新手入门电子书、教程、源码等等，收费分享给大家！想要的返回“Python 编程学习圈”，发送“J”即可收费取得