pip生态中与package.json真正等效的标准化配置文件是什么？

Great question! I totally get why you'd want a standardized, non-Python config file instead of setup.py—parsing code programmatically is a hassle, and having a structured format like package.json makes tooling and automation way smoother.

The good news is that the Python community has settled on pyproject.toml as the official, standardized config file for package metadata, dependencies, and tooling configuration. It's formalized in PEP 621 and is now supported by all major tools like pip, setuptools, poetry, and flit.

What pyproject.toml Covers #

Unlike requirements.txt (which only handles runtime dependencies), pyproject.toml lets you define all the metadata you'd put in setup.py plus more:

• Package name, version, authors, description, and homepage
• Runtime dependencies (can replace requirements.txt for packaging purposes)
• Python version constraints
• Entry points (like CLI commands or plugin hooks)
• Build dependencies (e.g., tools needed to compile your package)
• Configuration for other tools (linters, test runners, formatters)

Example pyproject.toml #

Here's a minimal example that covers core metadata and dependencies:

[project]
name = "my-cool-package"
version = "0.1.0"
authors = [
  { name = "Julian Dm", email = "your-email@example.com" }
]
description = "A package that does awesome things"
readme = "README.md"
requires-python = ">=3.8"
dependencies = [
  "requests>=2.28.0",
  "pyyaml>=6.0"
]

# Define a CLI command (equivalent to entry_points in setup.py)
[project.scripts]
my-cli = "my_cool_package.main:run_cli"

Why It's Better Than setup.py for Your Use Case #

• Structured, non-Python format: TOML is easy to parse programmatically with Python's built-in tomllib (Python 3.11+) or the tomli backport for older versions. No need to execute Python code to extract metadata.
• Standardized: It's the official Python standard, so you don't have to rely on tool-specific formats.
• Unified config: You can keep all your package-related configuration in one place, not just metadata—for example, adding [tool.black] to configure the Black formatter, or [tool.pytest.ini_options] for pytest settings.

Parsing pyproject.toml Programmatically #

Here's a quick snippet to read metadata from pyproject.toml with standard libraries:

import tomllib

with open("pyproject.toml", "rb") as f:
    project_config = tomllib.load(f)["project"]

print(f"Package name: {project_config['name']}")
print(f"Author: {project_config['authors'][0]['name']}")
print(f"Dependencies: {project_config['dependencies']}")

Tooling Support #

If you're using a package manager like Poetry or Flit, they'll leverage pyproject.toml as their primary config file. Poetry even adds extra sections (like [tool.poetry]) for advanced features, but it also supports the standard [project] section for compatibility with other tools.

Final Notes #

requirements.txt is still useful for sharing runtime dependencies with users who just want to install your package without using a package manager, but pyproject.toml is now the single source of truth for all package metadata and build configuration—exactly like how package.json works in JavaScript.

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