跳转到主要内容

Python项目结构基础或模板,CLI控制台脚本。

项目描述

PyPI latest release version
PyPI downloads per month
PyPI Python versions
Python code style
GitLab latest release
GitLab CI/CD pipeline status
GitLab coverage report
GitLab repo stars
GitHub release (latest SemVer)
GitHub Actions status
Codecov test coverage
GitHub repo stars
Docker Hub image version (latest semver)
Docker Hub image pulls count
Docker Hub stars
Docker Hub image size (latest semver)
KeyBase PGP key ID
GitHub followers count
LiberaPay donated per week
LiberaPay patrons count

这个仓库旨在用作一个最小且具有见解的基线,用于Python软件项目。它包括

  • 基本的Python“发行”/项目元数据

  • 具有子命令模板的命令行控制台脚本

  • 用于本地开发构建、测试和维护任务的Makefile

  • 为用户和开发人员提供的Docker容器镜像

  • 在用户和开发人员中运行测试的Docker容器镜像

  • 一个用于格式化所有Python代码的Makefile目标,包括使用Black进行样式设置

  • 一个针对Prospector厨房水槽linter配置,该配置运行所有可用的Python代码检查

  • 一个用于在多个Python版本中运行所有测试和linter的tox.ini配置,包括Prospector未提供的某些检查。

  • VCS钩子,强制执行常规提交以及在提交和推送时成功构建和测试,并在推送时发布说明。

  • Makefile 中设置目标和食谱,以自动化由 常规提交 控制的发布,以及面向最终用户的 Towncrier 发布说明

  • Makefile 中设置目标和食谱,以自动化升级要求和依赖项

  • Makefile 中的食谱/目标,用于本地开发和 CI/CD 平台

  • 集成这些 CI/CD 食谱/目标的 GitLab CI/CD 管道

  • 集成这些 CI/CD 食谱/目标的 GitHub Actions 工作流程/管道

预期用途是将此存储库添加为项目的 VCS 远程。这样,开发人员可以在我们进行与 Python 项目结构和工具相关的更改时合并此存储库中的更改。当我们添加特定类型的项目的结构(例如 CLI 脚本、Web 开发等)、框架(例如 Flask、Pyramid、Django 等)、库等时,将使用分支来表示每个此类变化,以便可以将不同变化共有的结构合并回特定变化的分支。

模板使用

这是一份关于如何将此项目模板应用到您的项目中的粗略指南。由于此类测试会非常元化,以至于创建和维护它们会极度浪费开发人员时间,因此请报告您遇到的问题,或者最好是弄清楚并提交一个包含更正的 PR 到本节。

  1. 选择合适的分支使用

    您的项目是 CLI 工具?Web 应用程序?您将使用哪个项目托管提供商和/或 CI/CD 平台?选择适合您项目的适当分支

    • dist:

      基本的 Python 发布,包括构建、测试、代码检查、代码格式化和从本地开发者签出进行发布。

    • cli:

      上述功能,以及支持提供可执行 CLI 的项目。

    • docker:

      dist 分支加上用于开发和最终用户/部署的 Docker 容器。

    • ci:

      上述功能,加上运行测试和代码检查的 GitLab CI/CD 管道作为 CI,以及从 develop 和 main 作为 CD 发布。

    • ci-cli:

      上述功能,加上 cli 分支。

    • 等等。

    不要在您的项目中使用 develop 或 main 分支,因为这些分支用于测试 CI/CD 自动发布流程,并且因此包含已升级的版本、发布说明和其他不应合并到真实项目中的发布工件。

  2. 协调 VCS 历史

    如果启动新项目

    $ git clone --origin "template" --branch "ci-cli" \
    "https://gitlab.com/rpatterson/python-project-structure.git" "./foo-project"
    $ cd "./foo-project"
    $ git config remote.template.tagOpt --no-tags
    $ git remote add "origin" "git@gitlab.com:foo-username/foo-project.git"
    $ git config remote.template.tagOpt --no-tags
    $ git switch -C "main" --track "origin/main"

    如果合并到现有项目中

    $ git remote add "template" \
    "https://gitlab.com/rpatterson/python-project-structure.git"
    $ git config remote.template.tagOpt --no-tags
    $ git merge --allow-unrelated-histories "template/ci-cli"
  3. 重命名由项目名称派生出的文件和目录路径

    $ git ls-files | grep -iE 'python.?project.?structure'
  4. 重命名项目文件中由项目名称和模板作者身份派生出的字符串

    $ git grep -iE 'python.?project.?structure|ross|Patterson'
  5. 检查 # TEMPLATE: 注释并根据适当更改

    这些是需要开发人员注意和推理以采取正确行动的部分。因此,请仔细阅读注释并妥善处理它们。

    $ git grep "TEMPLATE"

最后,从此 ./README.rst 中删除此部分,并根据您的项目适当更新其余内容。随着上游模板的修复和功能的添加,您可以将它们合并到您的项目中,并根据需要重复步骤 3-5。

此模板在 develop 分支的所有推送上发布预发布版本,在 main 分支的所有推送上发布最终发布版本。项目所有者可以决定哪些类型的更改应该在最终发布之前进行预发布,哪些类型的更改应该直接进入最终发布。例如,他们可以决定

  • 非维护者或所有者的贡献应合并到 develop。有关此类公共贡献政策和工作流程的示例,请参阅 ./CONTRIBUTING.rst 文件

  • 对于最终发布中的错误修复,可以提交到 main 分支的分支,并在所有测试和检查通过后,将其合并回 main 以立即发布最终版本。

  • 对于安全更新的一般版本升级,也可以像错误修复一样合并到 main

安装

通过本地、本机安装或Docker容器镜像安装和使用

本地/原生安装

使用任何用于安装标准Python 3分发的工具进行安装,例如 pip

$ pip3 install --user python-project-structure

通过 argcomplete 提供可选的shell自动补全。

Docker 容器镜像安装

推荐通过 Docker Compose 使用Docker容器镜像。有关示例配置,请参阅 示例 ./docker-compose.yml 文件。配置完成后,您可以创建和运行容器

$ docker compose up

或者,您可以直接使用镜像。拉取 Docker 镜像

$ docker pull "registry.gitlab.org/rpatterson/python-project-structure"

然后使用镜像创建和运行容器

$ docker run --rm -it "registry.gitlab.org/rpatterson/python-project-structure" ...

发布图像变体标签用于Python版本、分支和主要/次要版本,以便用户可以控制他们在一段时间内获取新图像的时间,例如 registry.gitlab.org/merpatterson/python-project-structure:py310-main。推荐的Python版本是3.10,它是没有 py### 标签的版本,例如 registry.gitlab.org/merpatterson/python-project-structure:main。预发布版本来自 develop,最终发布版本来自 main,也是没有分支标签的默认版本,例如 registry.gitlab.org/merpatterson/python-project-structure:py310。主要/次要版本标签仅应用于最终发布图像,并且没有相应的 main 分支标签,例如 registry.gitlab.org/merpatterson/python-project-structure:py310-v0.8

发布多平台Docker镜像,包含以下平台或架构的图像,Python 3.10 py310 变体

  • linux/amd64

  • linux/arm64

  • linux/arm/v7

使用

有关选项和参数的详细信息,请参阅命令行帮助

$ python-project-structure --help
usage: python-project-structure [-h]

Python project structure foundation or template, top-level package.

optional arguments:
  -h, --help  show this help message and exit

如果使用Docker容器镜像,也可以从命令行运行容器

$ docker compose run "python-project-structure" python-project-structure --help
usage: python-project-structure [-h]

Python project structure foundation or template, top-level package.

optional arguments:
  -h, --help  show this help message and exit

贡献

注意:此项目托管在GitLab上。在GitHub上有一个镜像 https://github.com/rpatterson/python-project-structure,但请使用GitLab来报告问题、提交PRs/MRs以及任何其他开发或维护活动。

有关如何开始开发的更多详细信息,请参阅 ./CONTRIBUTING.rst 文件

动机

有那么多其他Python项目模板,为什么还要再做一个呢?我从1998年开始做Python开发,所以我有很多时间形成自己的看法。

我想要的模板是完整的工具链(例如:测试覆盖率、代码检查、格式化、CI/CD等),但依赖、结构和观点尽量保持最小化(例如:不使用Python构建/任务系统,框架/库的结构不一定是必需的等)。我一直找不到这样一个平衡的模板,所以我们才有了这个。

我还发现很难从其他模板中看出为什么他们做出了这样的选择。因此,我也将这个模板作为一种尝试不同Python开发选项并自行评估的方式。您可以在提交历史中了解我的发现和选择这些选项的原因。

然而,最重要的是,我从未找到一种令人满意的方法来随着时间的推移保持项目结构更新。因此,主要动机是利用这个仓库作为远程仓库,我们可以从使用该模板的项目生命周期中合并结构更新。

项目详情


发布历史 发布通知 | RSS源

下载文件

下载适合您平台的文件。如果您不确定选择哪个,请了解更多关于安装包的信息。

源代码分发

python-project-structure-0.8.25.tar.gz (57.6 kB 查看哈希值)

上传时间 源代码

构建分发

python_project_structure-0.8.25-py3-none-any.whl (12.2 kB 查看哈希值)

上传时间 Python 3

支持者