Python 项目工程化最佳实践指南

Python 工程化这件事都没有统一的规范和项目管理的方案，也许是因为 Python 突然兴起的时间较短、用于开发大型项目的公司较少。所以为了帮助内部的同学更好的解决 Python 工程化问题和分享下个人的开发习惯和代码管理思路写下这篇文章。

依赖管理

在 PEP 518 和 pyproject.toml 引入之前。一个项目无法告诉一个像 pip 这样的工具它需要什么样的构建工具来构建。现在 setuptools 有一个 setup_require 参数来指定构建项目所需的东西，但是除非你安装了 setuptools，否则你无法读取该设置，这意味着你不能声明你需要 setuptools 来读取 setuptools 中的设置。这个鸡和蛋的问题就是为什么像 virtualenv 这样的工具会默认安装 setuptools，以及为什么 pip 在运行一个 setup.py 时总是会注入 setuptools 和wheel，不管你是否显式地安装了它。你甚至不要尝试依赖于 setuptools 的一个特定版本来构建你的项目，因为你没有办法来指定版本; 不管用户碰巧安装了什么，你都得将就使用。

在 PEP 518 之后你可以声明你的构建工具以及要求的版本。

在过去我们可能会经常使用 requirements.txt 之类的文件来保存我们项目所需的依赖，但是它并没有很好的办法去区分我们在生产环境、开发环境、测试环境所需要的依赖必须要分成多份文件单独声明，通过一些新的构建工具我们就可以解决我们的问题。而且单独用 requirements.txt 也不能声明我们需要的 python 版本、系统环境等等。

在这次的内部项目开发中，我选择的是 PDM，PDM 旨在成为下一代 Python 软件包管理工具。它最初是为个人兴趣而诞生的。如果你觉得 pipenv 或者 poetry 用着非常好，并不想引入一个新的包管理器，那么继续使用它们吧；但如果你发现有些东西这些工具不支持，那么你很可能可以在 pdm 中找到。

Poetry 看起来也是个不错的选择，Poetry 和 Pipenv 、PDM 类似，是一个 Python 虚拟环境和依赖管理工具，另外它还提供了包管理功能，比如打包和发布。你可以把它看做是 Pipenv 和 Flit 这些工具的超集。它可以让你用 Poetry 来同时管理 Python 库和 Python 程序。

如果你用的是 PDM 或者 Poetry 请先在项目目录中，通过 virtualenv 创建一个叫 .venv 或者类似的文件夹。为什么我推荐 virtualenv 而不是 PEP582 呢？在很多系统下都依赖了一个默认的 python 版本，如果用 PEP582 的话，默认会使用系统自带的 python 版本，如果不用的话我们又必须额外的要生成一个需要的 python 版本对应的虚拟环境；其次是目前 vscode 并不支持。

我们可以利用这些构建工具，将我们的开发环境、测试环境、生产环境的依赖都区分开来。

我们同样可以在 pyproject.toml 中增加构建工具的额外命令，比如可以增加用于启动服务的 start 命令、测试用的 test 命令等等。类似 PDM Scripts 所描述的一样。通过构建工具启动服务能很有效解决包所在位置的问题，强制让所有的包的运行目录都为项目根目录。

项目结构

推荐的项目结构如下：

Dockerfile

这个文件主要用于给 Docker 构建镜像使用，建议在生产环境部署时通过 Docker 进行部署。

docs

专门用于保存文档的文件夹。

LICENSE

如果这个是一个开源项目，那么这个文件一般用于放置使用的开源协议。

pyproject.toml

基于 PEP518 规范的配置文件，保存