Description
PR #1495 introduced support for declaring apt dependencies in an app's pyproject.toml using the [deploy.dependencies.apt] table:
[deploy.dependencies.apt]
packages = [
"ghostscript",
]
However, [deploy] is not a valid top-level key in pyproject.toml per the packaging specifications.
Why this is a problem
PEP 518 defines only three recognized top-level tables:
[build-system]
[project]
[tool]
All other top-level keys are explicitly reserved for future use by standards. Using [deploy] risks clashing with a future PEP and goes against the established convention.
The [tool] table exists precisely for this purpose — tool-specific configuration that is not part of the standard. Bench already uses [tool.bench.dev-dependencies] and [tool.bench.frappe-dependencies] correctly.
Suggested fix
Move the section under [tool.bench] to stay consistent with existing bench keys:
[tool.bench.deploy.dependencies.apt]
packages = [
"ghostscript",
]
And update the parsing logic in Press accordingly.
References
Description
PR #1495 introduced support for declaring apt dependencies in an app's
pyproject.tomlusing the[deploy.dependencies.apt]table:However,
[deploy]is not a valid top-level key inpyproject.tomlper the packaging specifications.Why this is a problem
PEP 518 defines only three recognized top-level tables:
[build-system][project][tool]All other top-level keys are explicitly reserved for future use by standards. Using
[deploy]risks clashing with a future PEP and goes against the established convention.The
[tool]table exists precisely for this purpose — tool-specific configuration that is not part of the standard. Bench already uses[tool.bench.dev-dependencies]and[tool.bench.frappe-dependencies]correctly.Suggested fix
Move the section under
[tool.bench]to stay consistent with existing bench keys:And update the parsing logic in Press accordingly.
References