python - 自动化Python软件包发布过程

Question

我刚刚启动了一个开放源代码Python项目，希望有一天它会流行起来。目前要发布新版本，我必须做一些事情。


测试所有东西。
编辑mypackage.VERSION变量，该变量从setup.py导入。
使用__init__构建包装和轮子
将更改日志条目写入python setup.py sdist bdist_wheel文件
提交我的更改，回显一些更改日志
标记为发布的标签，再次复制该变更日志条目。
拖入我的内置文件，以便人们可以从发行版中下载它们
使用Twine将软件包推到PyPI上
通过PyPI在我的登台服务器上再次测试。


如果我必须以九个要点来总结我对项目的所有不满，我想我们会在一个非常相似的列表中找到。切入的是过去我编了一个新版本号并写了commit / changelog消息，这很痛苦。

我是否可以通过某种方式使任何这些任务自动化，例如，让GitHub CI可以仅通过提交完成所有任务？

我已经拥有十年的Python经验和一点CI，但是对于打包Python并与PyPI进行积极交互我还是很陌生。我怀疑我不是唯一一个在这里因手动重复而发疯的人，我只是在寻找可以简化此过程的工具（或服务）。

Answer 1

以下是我对您的清单的看法。您可以实现一定范围的自动化，而我将尝试提供一个合理的起点，然后提供一些提示，告诉您如何进一步发展。



没有CD的CI

采用这一部分应该已经摆脱了大多数烦人的手工工作，并且随着需求的增加，您可以实现越来越多的自动化。如果您不愿意维护大量的CI代码，则应从这里开始。

您需要的是CI（如前所述）和程序包管理器。您无法解决的事情是使用git推送您的更改和新标签，因此第5步和第6步的部分内容仍为手动操作。

包装管理

我将使用poetry来保持内容简洁，因为我喜欢[1]，但是也有other options。这将涉及步骤2、3、7、8和未列出的步骤10“更新我的依赖关系并测试它们的兼容性”，一旦发现有问题，这将令人讨厌。

使用诗歌时的坏消息是，您需要将所有打包配置都移到新文件pyproject.toml中。好消息是，您不再需要单独的setup.py，setup.cfg，MANIFEST.in或requirements.txt，因为pyproject.toml是包装和其他工具的临时标准，诗歌也有关于如何移植所有相关信息的walkthrough。

设置就绪后，新的部署工作流程将是：

$ poetry update           # update dependencies, may be skipped 
$ poetry version          # bump version
Bumping version from 1.1.2 to 1.1.3
# finalize git stuff, e.g. add -u, commit -m 'v1.1.3', tag v1.1.3, push
$ poetry publish --build  # build and publish to PyPI
Building my_django_lib (1.1.3)
 - Building sdist
 - Built my_django_lib-1.1.3.tar.gz

 - Building wheel
 - Built my_django_lib-1.1.3-py3-none-any.whl

Publishing my_django_lib (1.1.3) to PyPI
 - Uploading my_django_lib-1.1.3-py3-none-any.whl 100%
 - Uploading my_django_lib-1.1.3.tar.gz 100%

这应该已经比您目前正在做的要短得多。如果您始终执行完全相同的git命令，不怕自动执行推送，并妥善保管 .gitignore文件，请随时在 ~/.bashrc中添加类似此函数的内容并改为调用它：

git_cord () {
  version=$(grep pyproject.toml -e '(?<=^version = ")(.*)(?=")' -Po)
  git add -u
  git commit -m "${version}"
  git tag "${version}"
  git push -u origin "${version}"
}

gitlab-CI入门

CI原则上可以处理部署过程中的所有事宜，包括版本变更和发布。但是第一个要求您的CI可以推送到您的存储库（具有令人讨厌的副作用），而第二个要求它可以将其发布到PyPI（这是有风险的，并且使调试CI变得很痛苦）。我认为喜欢手工完成这两个步骤并不稀奇，因此这种最小的方法只能处理步骤1和9。此后可以包括更广泛的测试和构建工作。

配置项的正确设置取决于您计划使用的配置项。 list for github很长，因此我将重点介绍gitlab的内置CI。它是免费的，几乎没有什么魔力（可移植性相对较低），并且CI运行程序的二进制文件是 open, free, and actually documented，因此您可以在本地调试CI或在免费运行程序没有切入CI的情况下启动并连接新的运行程序。您。

您可以在项目根目录中放入一个小的 .gitlab-ci.yml来运行测试。流水线中的每个作业（跳过设置和安装命令）也应该在您的开发环境中可执行，这样可以保持更好的维护经验。

image: python:3.7-alpine

stages:
  - build
  - test

packaging:
  stage: build
  script:
    - pip install poetry
    - poetry build
  artifacts:
    paths: 
      - dist

pytest:
  stage: test
  script:
    - pip install dist/*.whl
    - pip install pytest
    - pytest

像这样设置 build和 test阶段可一次完成第1步和第9步，同时还针对已安装的软件包而不是源文件运行测试套件。尽管只有在您的项目中有src布局时，它才能正常工作，这会使本地资源无法从项目根目录导入。关于为什么 here和 here是个好主意的一些信息。

诗歌可以创建一个src-layout模板，您可以使用 poetry new my_django_lib --src将代码移入其中。

变更日志

尽管有一些工具可以从提交消息中获取 automatically create a changelog，但 keeping a good changelog却是从手工维护中受益匪浅的东西之一。因此，我的建议是步骤4不自动化。

考虑它的一种方法是，手册 CHANGELOG文件包含与用户相关的信息，并且仅应包含新功能，重要的错误修正和不推荐使用的信息。

对于贡献者或插件编写者而言可能更重要的更细粒度的信息将位于MR，提交消息或进行讨论中，而不应将其放入 CHANGELOG中。您可以尝试以某种方式收集它，但是导航这样的 AUTOLOG可能与筛选我刚才提到的主要资源一样麻烦。

简而言之，可以跳过步骤5和6中与变更日志相关的部分。



带CD的CI

添加CD不会发生太大变化，只是您不必手动释放。如果CI中断，越野车出现，或者您不想等待管道发布修补程序，您仍然可以以诗歌形式发布。

这将通过以下方式更改工作流程：


日常工作


编写代码（尚无法避免）
在提交消息和/或MR中记录进度（我更喜欢MR，即使是我自己进行更改，也压缩合并时的所有提交）
推送到gitlab /合并MR

发布时


创建一个标签，运行 poetry version，也许运行 poetry update
在 CHANGELOG中写发行说明
推送到gitlab



如果您 supply the secrets .gitlab-ci.yml和 PYPI_USER，对前 PYPI_PASSWORD文件的此添加应立即起作用：

stages:
  - build
  - test
  - release

[...]  # packaging and pytest unchanged

upload:
  stage: release
  only:
    - tags
    # Or alternatively "- /^v\d+\.\d+\.\d+/" if you also use non-release
    # tags, the regex only matches tags that look like this: "v1.12.0"
  script:
    - pip install poetry
    - poetry publish -u ${PYPI_USER} -p ${PYPI_PASSWORD} dist/*

一些有用的链接：


.gitlab-ci.yml documentation
list of predefined variables，这是大多数gitlab CI晦涩的地方
我的 .gitlab-ci.yml模板的 the long version，以及可能对您有用或不有用的其他阶段。它期望代码的src布局。


lint： type checking， coverage和 code style
security：检查 your own code和 your dependencies的价差
release.docs：公共gitlab页面部分，在其中提供自动创建文档的文档 based on your docstrings
build阶段从 poetry.lock文件创建一个操舵室，该操舵室可用于以后安装依赖项以支持PyPI。这样可以更快一点，可以节省网络带宽，并且可以在需要调试时声明使用特定版本，但是这样做可能会过大，并且需要使用诗歌预发行版。





[1]除其他事项外，诗歌还（1）为您处理virtualenv，（2）创建散列的锁定文件，以防您需要可复制的构建，以及（3）使贡献更容易，因为克隆后只需运行“诗歌安装”即可。回购，并准备开始。