pyloong / cookiecutter-pythonic-project Goto Github PK

问题描述

经测试，在 setup.cfg 文件中的 [options.package_data] 指定数据文件后，通过 python -m build 打包，生成的 sdist 源码包中没有数据文件，生成的 whl 二进制包中有数据文件。当相同的数据文件出现 [options.data_files] 中时， sdist 源码包中有数据文件。

根据 Python Packaging User Guide 文档 Including files in source distributions with MANIFEST.in 中有这么一句 all files specified by the package_data and data_files setup() arguments ，只能根据上面结果猜测是两个条件都存在时才有效。

根据 Setuptools 文档 Data Files Support 中有提到，当配置 include_package_data=True 参数时，要加载的数据文件必须在 MANIFEST.in 文件中指定。但继续描述说如果需要更精准的控制数据文件，可以使用 package_data 关键字。我的理解是存在一个 或 的关系，而在 whl 二进制包也确实是这样，只不过 sdist 源码包有区别。

在此做出猜想，要么是打包时，加载逻辑出现了 Bug ，要么是描述有问题。而且现在打包相关的工具在疯狂迭代。所以做出兼容可能是更好的选择吧。

解决思路

在项目模板中增加 MANIFEST.in 文件，方便配置打包时要加载的数据文件。

MANIFEST.in 示例文件

一个 Django 项目的示例文件

include MANIFEST.in
include LICENSE
include *.md
graft docs
graft tests
recursive-include src/globiz_rates fixtures/*.json
global-exclude __pycache__
global-exclude *.py[co]

按照文档初始化出项目模板，命名为 py_project，加入示例 counter.py 以及对应测试用例后，运行 pytest 报错
排查之后，把 py_project 目录从 src 目录中移出，问题解决。

问题是如果要保持 src 的目录组织结构，怎么做调整，使 pytest 引入模块不报错

背景

根据 2019-06-04 发布的 PEP 602 - Python的年度发布周期 中描述：

1.5 年（17 个月）开发一个大版本

• 前五个月的预发布版。会和上一个版本的 Beta 版本 + RC 版本阶段重合
• Python 从 Python 3.9 版本开始，包括以后的版本。会用 7 个月进行 7 个 alpha 版本开发。
• 接下来的三个月进行 4 个 Beta 版本的开发。
• 然后两个月进行至少两个候选版本的开发，并发布该阶段版本的最终版本。

5 年的支持

• 发布版本会进行 1.5 年（18 个月） 的全面支持
• 接下来会进行 3.5 年（42 个月）的安全修复

年度发布节奏

Python 3.(X+1).0 在会在Python 3.X.0 Beta 1 发布后，开始新版本的开发。即每年开发一个新版本。

发布路线图：

动机

Python 3.7 的一个重大改动，是将 Asyncio 作为内置模块可用。在后面的 Python 3.8 和 Python 3.9 都对异步做了大量的优化和改进。同时后面两个版本也对类型标注和检查做了很大的改进。

再了解社区情况，现在大量第三方库已经做了对 Python 3.9 的支持，进行了 CI 测试。少量第三方库已经进行了 Python 3.10 的测试。

在操作系统上，Ubuntu 和 Centos 的最新发新版，都自带了 Python 3.9 。据了解， AWS 的一些环境默认也是 Python 3.9 。

鉴于社区使用程度，现在有必要将 Python 的升级计划提上日程。以便未来的新项目能直接从 Python 3.9 开始，减少日后适配项目的数量。

实施

• 将仓库本身的 Python 环境升级到 Python 3.9
• 将项目模板的 Python 环境升级到 Python 3.9

问题描述

如果交互提示输入的项目名结尾有空格，会出现如下情况：

project_name [My Project]: globiz-rates 
project_slug [globiz_rates_]: 

修复

自动删除结尾空格

tasks:

• change poetry dev dep to dev group
• update console script config
• add pytest config
• add pylint config
• add tox to dev group deps

change dev dep to dev group

The --dev option is deprecated, use the `--group dev` notation instead.

console script config not effect

ref: https://python-poetry.org/docs/pyproject/#scripts

config error:

actually:

[tool.poetry.scripts]
my_package_cli = 'my_package.console:run'

原因：

gh-action 中 使用 matrix 策略没有正确配置 python 版本，导致在执行 test 时，使用 os 的默认版本 python 3.8

修复：

• 为 test 的 python action 增加引用版本
• 为 lint 的 python action 增加引用版本

相关资料： Using a matrix for your jobs ，actions/setup-python

示例

      - uses: actions/setup-python@v4
        with:
          python-version: "3.10"

动机

PEP-484 的新特性在社区应用越来越广泛。而且越来越多的工具都在新版本中逐步适配静态类型，并使用 mypy 进行检查。

这么做的目的是为了尽早的在编码阶段发现程序中可能出现的错误。

实施

• 为仓库本身增加静态类型和 mypy 检查相关逻辑，如 tox 和 CI
• 为项目模板增加静态类型和类型检查

目的

为了强调 Git 的使用，在项目完成后，默认执行一次 Git 提交。这么做有两个好处：

• 可以提示开发人员优先使用 Git 操作
• 让初始化项目变成一个操作单元
• 方便操作失误进行回退到最初状态，避免重新初始化一次项目。

解决方式：

在 cookiecutter 的 post_hook 中使用多进程调用 Git 的命令行，对项目进行一次初始化提交。

因为缺少setup.py文件，无法执行python setup.py sdist bdist_wheel命令。

文档和模板不匹配？

参考文档地址：快速上手 - 打包

问题描述

在项目模板中的 gitlab-ci.yml 文件中，仍然使用 python setup.py 构建项目。由于之前已经调整使用 PEP-517 规范，此时应该使用 python -m build 构建

在生成项目时，选择使用 github 的 CI 时，生成的 gitflows 文件有错误存在。

异常信息

The workflow is not valid. Job deploy depends on unknown job build.

原因

gitflow 中的 deploy 任务依赖的的 build 任务不存在。

解决

deploy 任务依赖 test 任务和 lint 任务

  deploy:
    if: github.event_name == 'push' && startsWith(github.event.ref, 'refs/tags') && github.repository == 'file2mongo'

    runs-on: ubuntu-latest

    needs:
      - test
      - linting

说明

使用 base_dir 传递到配置对象中，使用 settings.BASEDIR 是获取不到的，应该使用 settings.BASE_DIR

修复

settings.BASEDIR -> settings.BASE_DIR