Thanks for writing this up!
In general I think the PEP is aiming in a good direction, though I think if we’re introducing a table with a name as fundamental as “requirements”, we should IMO not key it with such an ambiguous name as “packages”. Quoting from another discussion
In the meantime, PEP 725 is also proposing external.{build-requires, host-requires, dependencies}, as well as optional- versions of all those.
This is creating a zoo of ways for specifying various kinds of requirements, which is becoming increasingly confusing and inconsistent IMO. Therefore, I would really like to not close the door to eventually have requirements become a unified home for all those in some way.
IOW, if we choose requirements.packages today, we close the door on that for a long time, because it’s not clear which packages (build, host, external, wheel-build, run-time, etc.). It’d be great if we could choose a name like requirements.run for this (in the quoted post above, I used [dependencies.run] and [dependencies.optional] as strawmen – I care much less about the exact naming than about having a consistent API for dependency specification at some point)
original quote said
run.{...}, I adapted it for this discussion. ↩︎