非可安装Python项目能否使用pyproject.toml？是否符合Python风格？

1. 非可安装项目用pyproject.toml是否符合Python风格？ #

完全符合。自从PEP 621将pyproject.toml确立为Python项目的标准配置文件后，它的用途早已不限于可安装包的构建配置。现在大量工具（比如你提到的ruff，还有pre-commit、pytest等）都支持通过pyproject.toml管理自身配置，同时它也能用来统一声明项目依赖。这种做法是现代Python开发的推荐实践，不管项目是否要打包成可安装包，用pyproject.toml统一管理配置和依赖都是合规且高效的。

2. 能不能不转成可安装包就使用pyproject.toml？ #

当然可以。你完全不需要调整项目结构为可安装包形式，就能用pyproject.toml完成核心需求：

• 工具配置：只需要添加[tool.*]类型的配置段，比如[tool.ruff]、[tool.pre-commit]，对应的工具会自动读取这些配置，和项目是否可安装无关。
• 依赖管理：如果需要用它声明依赖，可以添加基础的[project]段（仅需name和version字段即可），然后通过pip install -e .将依赖安装到当前环境，或者用poetry、pipenv这类工具基于pyproject.toml创建隔离环境。甚至不想加[project]段的话，也可以配合pip-tools从pyproject.toml生成requirements.txt。

举个极简的非可安装项目pyproject.toml示例：

[tool.ruff]
line-length = 120
select = ["E", "W", "F"]

[project]
name = "my-cron-job"
version = "0.1.0"
dependencies = [
  "pandas>=2.0",
  "requests>=2.31",
]

这个配置不需要项目有可安装包的结构，照样能让ruff读取规则，也能通过pip install -e .安装依赖。

3. 是否应当将所有项目都转为可安装包？ #

没必要一刀切，根据项目复杂度和需求判断：

• 不需要转的情况：如果是单文件的简单脚本（比如几百行的cronjob脚本），转成可安装包属于过度工程化，反而增加不必要的工作量。
• 建议转的情况：如果是多文件项目（比如包含多个模块、工具函数的API服务或数据处理项目），转成可安装包有明显优势：
  • 不用手动处理sys.path，模块导入更规范；
  • 可以通过entry-points定义命令行脚本，部署和调用更方便（比如systemd服务直接调用脚本命令，无需写绝对路径）；
  • 依赖管理更严谨，部署时可直接通过pip安装包，不用复制整个项目目录；
  • 方便用pytest等工具进行测试，模块导入更顺畅。

转成可安装包的成本很低：只需要在pyproject.toml里完善[project]段（指定name、version），添加packages = ["your_project_name"]或packages = [{ find = {} }]让工具自动发现包结构，再把代码放到对应名称的目录下（Python 3.3+可不用__init__.py，但建议添加）即可。

内容的提问来源于stack exchange，提问作者ddxv