The discussion on PEP 621: Storing project metadata in pyproject.toml has gotten long enough that I wanted to break out and explicitly call out the open issue in the PEP: how to specify dependencies? Basically the authors couldn’t agree between using PEP 508 string specifiers (like how Flit does it or go with a table approach like how Poetry or pipenv do it. The relevant parts of the PEP is pasted below.
requiresfor required dependencies,
for optional dependencies
[tool.poetry.dependencies]for dependencies (both
required and for development),
[tool.poetry.extras]for optional dependencies
install_requiresfor required dependencies,
extras_requirefor optional dependencies
See the open issue on
How to specify dependencies?_ for a
discussion of the options of how to specify a project’s dependencies.
How to specify dependencies?
People seem to fall into two camps on how to specify dependencies:
508 strings or TOML tables (sometimes referred to as the
“exploded table” format due to it being the equivalent of translating
508 string into a table format). There is no question as to
whether one format or another can fully represent what the other can.
This very much comes down to a question of familiarity and (perceived)
ease of use.
Supporters of :pep:
508 strings believe familiarity is important as
the format has been in use for 5 years and in some variant for 15
years (since the introduction of :pep:
345). This would facilitate
transitioning people to using this PEP as there would be one less new
concept to learn. Supporters also think the format is reasonably
ergonomic and understandable upon first glance, so using a DSL for it
is not a major drawback.
Supporters of the exploded table format believe it has better
ergonomics. Tooling which can validate TOML formats could also help
detect errors in a
pyproject.toml file while editing instead of
waiting until the user has run a tool in the case of :pep:
Supporters also believe it is easier to read and reason (both in
general and for first-time users). They also point out that other
programming languages have adopted a format more like an exploded
table thanks to their use of standardized configuration formats (e.g.
Dart <https://dart.dev/tools/pub/dependencies>). The thinking
is that an exploded table format would be more familiar to people
coming to Python from another programming language.
The authors briefly considered supporting both formats, but decided
that it would lead to confusion as people would need to be familiar
with two formats instead of just one.