目录

• 简介
• 环境搭建
• 配置
  • 1. pyenv
    • 选择的原因
    • 安装
  • 2. Poetry
    • 选择的原因
    • 安装
    • 创建虚拟环境
    • 管理依赖
  • 3. pipx
    • 选择的原因
    • 安装使用
    • 基本使用
  • 4. Docker
  • 5. 不再使用的

简介

最近两年做工具都在逼自己用刚学不久的 Go 和 Rust ，对 Python/Django 有些疏远了。最近想做一个 OKR 管理和对齐的工具，想着 Python 2 总算正式退役了， virtualenv 也改名 venv 成了标配，不如宠幸一把试试感觉。

结果光是包和依赖管理，就有 pip-tools/pyenv/Anaconda/pipenv/poetry/pipx/…，WTF，贵圈是被前端社区统治了吗…

大概看了一下各路的妖魔鬼怪，我觉得可以选一套自己还比较满意的工具链记录和分享一下。分为下面几个部分：

1. 环境搭建
2. 测试框架
3. 静态检查
4. 类型检查

环境搭建

我的需求：

• 为各种不同项目管理和隔离它们的运行时环境（主要是 Python 版本）和依赖
• 保持 Mac 系统本身的干净，包括自动的 Python 不被覆盖，全局生效的 zsh 配置等尽量不动
• 部署项目的时候尽量使用 Docker ，但是在使用上它又慢又重又容易撞墙

配置

1. pyenv

选择的原因

pyenv 应该主要是借鉴了 nodenv，让你：

• 可以安装多个 Python 版本然后根据需要在全局或者为每个项目配置
• 可以和 tox 结合测试你的应用在不同 Python 版本下的运行情况
• 可以结合 pyenv-virtualenv 对虚拟环境进行管理（我没有用，因为 Poetry 自带的对 venv 功能的封装足够用了）

安装

可以使用 brew 来安装 pyenv，但是我希望对它更可控所以选择直接：

$ git clone https://github.com/pyenv/pyenv.git 〜/.pyenv

因为我使用 zsh，所以在 ~/.zshrc 里面可以加上：

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
$ echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.bash_profile

然后就可以安装不同版本的 Python 了：

$ pyenv install 3.8.1
$ pyenv install 3.7.2

查看有哪些可用版本然后配置全局优先使用 3.8.2 版本：

$ pyenv versions
  system
  3.7.2
  3.8.1
$ pyenv global 3.8.1

然后可以选择安装 pyenv-virtualenv，但是我打算用 poetry 来创建和激活虚拟环境，所以就没有安装。

2. Poetry

选择的原因

Poetry 使用了类似于前端生态里的 yarn 或者 bundler 的架构来做三件事情：

• 管理依赖
• 打包应用
• 管理虚拟环境

如果你不想被 docker 拖垮可以试试这个。

安装

使用 curl 安装然后配置环境变量：

$ curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python

$ echo 'export PATH="$HOME/.poetry/bin:$PATH"' >> ~/.zshrc

安装后可以把生成虚拟环境的路径指定到项目的根目录：

$ poetry config virtualenvs.in-project true

新建一个测试项目：

$ poetry init --no-interaction

这会创建一个 pyproject.toml 文件：

[tool.poetry]
name = "test"
version = "0.1.0"
description = ""
authors = ["lenciel <lenciel@gmail.com>"]

[tool.poetry.dependencies]
python = "^3.8"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

然后你就可以用 TOML 语法来编辑这个文件了。

创建虚拟环境

virtualenv 被收编后改名为 venv，在我们声明了一个项目之后，通过下面的命令就会自动创建一个跟项目关联的虚拟环境：

$ poetry install
Creating virtualenv test in /Users/lenciel/Projects/engineering/test/.venv
Updating dependencies
Resolving dependencies... (0.1s)

Writing lock file

No dependencies to install or update

在这个虚拟环境下面运行程序可以使用：

$ poetry run python test.py

另外，可以通过配置让虚拟环境的目录就生成在项目的根目录来方便查看：

$ poetry config virtualenvs.in-project true

管理依赖

可以通过 add 命令来添加依赖：

$ poetry add django

Using version ^3.0.8 for django

Updating dependencies
Resolving dependencies... (1.1s)

Writing lock file


Package operations: 4 installs, 0 updates, 0 removals

  - Installing asgiref (3.2.10)
  - Installing pytz (2020.1)
  - Installing sqlparse (0.3.1)
  - Installing django (3.0.8)

这个操作其实会：

• 下载并安装所有的依赖包到虚拟环境
• 安装好后依赖的详细信息会被注册到 poetry.lock 文件
• 依赖的版本信息会被注册到 pyproject.toml

如果你熟悉前端的工具链这个就很像对 gem 的管理。包括 pyproject.toml 的依赖版本描述语法，比如 ^1.3.0 表示不低于 1.3.0 的版本。而 poetry.lock 文件里的版本则是具体被安装的版本，它可以用来保持整个团队的版本一致性，以及生产环境和开发环境的版本一致性。

当需要更新某个依赖的时候，你即可以用 update 命令，也可以用类似 poetry add django^3.0.1 来指定更新到具体的版本。

3. pipx

选择的原因

pipx 和 pip 不一样的是它不仅仅是一个包管理工具，它会创建一个虚拟环境，然后让你很容易的运行某个制定的程序而不用担心影响到其他地方。基本上你可以把它理解成 pipsi 的续篇就好

安装使用

保障干净（YMMV）的安装方法：

$ python -m pip install pipx

基本使用

$ pipx install sphinx

inject 可以让你在 REPL 里面安装额外的包并直接 import:

$ pipx inject sphinx sphinx_rtd_theme

4. Docker

Docker 其实跟 Python 的环境搭建和依赖管理没有任何直接关系，但是大家经常在这种讨论中谈到它，因为容器技术的一大用途就是进行开发环境的搭建。

前面讨论的以及后面会讨论的所有东西，当然都可以安装到容器里面。而且说实话，你要为每个 Python 的应用建一个容器，那虚拟环境可能都不需要了。但我个人觉得，Docker 也有下面的缺点：

• 比较重，从安装到使用到运行需要的资源
• 调试起来需要大量的配置和对工具链额外的投入
• 安装很多跟系统底层相关的依赖时比较麻烦
• 实际上还是需要你至少使用 pip 等来管理依赖，换句话说，你只是在容器里面去执行前面说的那些命令而已

所以如果不是公司在容器化上有足够投入，并且你开发的应用也不涉及到 Python 以外的组件和依赖（例如，你开发的是 Django 的应用，还涉及 数据库，Nginx ，Gunicorn 等等别的依赖，Docker 可能就挺好用的），我是不推荐使用 Docker 的，可以做一个具体的对比：

5. 不再使用的

下面两个是在之前工具链里面被直接去掉的：

• virtualenv（Python 3.0 自带 venv）
• pipsi （pipx 比它好用）

还有一个就是 virtualenvwrapper ，但我比较怀念在目录切换的时候自动 activate/deactivate 相应的虚拟环境，并且在 zsh 的 prompt 上有一个提示，这个可以用脚本：

#!/usr/bin/env zsh
ZSH_POETRY_AUTO_ACTIVATE=${ZSH_POETRY_AUTO_ACTIVATE:-1}
ZSH_POETRY_AUTO_DEACTIVATE=${ZSH_POETRY_AUTO_DEACTIVATE:-1}
ZSH_POETRY_OVERRIDE_SHELL=${ZSH_POETRY_OVERRIDE_SHELL:-1}

autoload -U add-zsh-hook

_zp_current_project=

_zp_check_poetry_venv() {
  local venv
  if [[ -z $VIRTUAL_ENV ]] && [[ -n "${_zp_current_project}" ]]; then
    _zp_current_project=
  fi
  if [[ -f pyproject.toml ]] \
      && [[ "${PWD}" != "${_zp_current_project}" ]]; then
    venv="$(command poetry debug 2>/dev/null | sed -n "s/Path:\ *\(.*\)/\1/p")"
    if [[ -d "$venv" ]] && [[ "$venv" != "$VIRTUAL_ENV" ]]; then
      source "$venv"/bin/activate || return $?
      _zp_current_project="${PWD}"
      return 0
    fi
  elif [[ -n $VIRTUAL_ENV ]] \
      && [[ -n $ZSH_POETRY_AUTO_DEACTIVATE ]] \
      && [[ "${PWD}" != "${_zp_current_project}" ]] \
      && [[ "${PWD}" != "${_zp_current_project}"/* ]]; then
    deactivate
    _zp_current_project=
    return $?
  fi
  return 1
}
add-zsh-hook chpwd _zp_check_poetry_venv

poetry-shell() {
  _zp_check_poetry_venv
}

if [[ -n $ZSH_POETRY_OVERRIDE_SHELL ]]; then
  poetry() {
    if [[ $1 == "shell" ]]; then
      _zp_check_poetry_venv || (
        echo 'pyproject.toml file not found' >&2;
        exit 1
      )
      return $?
    fi
    command poetry "$@"
  }
fi

[[ -n $ZSH_POETRY_AUTO_ACTIVATE ]] && _zp_check_poetry_venv

环境搭建就是这样，接下来是测试框架的选择和配置。