Yes, this will be added to the PyPA specifications section of the packaging guide. I didn’t mention that explicitly because it’s simply the normal process (even if it’s not always done as promptly as we’d like).
I like the syntax suggestions here. I agree that while I don’t want to extend this PEP beyond declaring dependencies, there’s clearly a possibility that people will want to add further data at some point, and so having something that’s extensible is important. So here’s a concrete proposal. My plan is for this to be the spec that goes into the next revision of the PEP, so feedback is appreciated - but at some point I have to draw a line and say “this is what I propose”, so any suggestions for particularly radical changes will at this point likely just get told “thanks, but no thanks” and go into the rejected alternatives.
Proposed Syntax
- A script can contain one or more “metadata blocks”, each consisting of a block of one or more consecutive lines starting with
##. Blocks end at the first line that doesn’t follow this format. - Leading and trailing whitespace are ignored in a block (so no significant indentation), as are lines with nothing but the
##marker. - The first line of a block is a header, and consists of a block name (which defines the block type), followed by a colon, optionally followed by data.
- Interpretation of the data on the header line, and of the rest of the block, depends on the block type.
The only block type defined in this PEP is Script Dependencies. This block cannot have data on the header line, and every other non-blank line in the block is required to be a PEP 508 dependency specifier.
(I’ll tighten up the specification in the actual PEP, but that should be clear enough to explain the idea).
Under this proposal, this would be
## Script Dependencies:
## click
## httpx
## GUI-Name: Download latest training data
The blank line is required, to separate the two metadata blocks.
To everyone who’s been proposing TOML in one form or another, I’m sorry, but that won’t be the proposed syntax. If someone wants to, they can propose a competing PEP that uses TOML. Or, given that I generally think that “competing PEPs” is an unhealthy approach, if someone wants to persuade @brettcannon (as PEP delegate) to declare that the spec should use TOML, then I’ll happily hand over authorship of this PEP to someone else to make that change. But I don’t think I could fairly represent a proposal that used TOML myself. I do intend to expand my reasoning in the relevant “rejected alternative” section of the PEP - what’s currently there relies too heavily on the argument that the PEP doesn’t need the complexity, and I think that’s insufficient once we start considering future extensions. But I don’t expect to change people’s minds - I’m just intending to document my reasons for the choices I’ve made.