Thank you for the detailed arguments you put into the PEP.
I will not respond to everything (to avoid repeating already-made arguments).
I do not agree that TOML would be a significant learning burden. In practice, all the beginner-type people are just going to just copy-paste the format found on StackOverflow/whatever, so whether it is actually TOML under the hood or some other special format makes little difference. The format specified in the PEP is not free of cognitive overhead (for example, the need to double the # for comments or the exact keywords Script Dependencies: with a colon and case-sensitive are things you could forget just as well as the [project] brackets or whatever part of TOML). To me,
## Script Dependencies:
## rich
## numpy
is not a significantly simpler format than, say,
"""pyproject.toml
[project]
dependencies = ["rich", "numpy"]
"""
I don’t really understand the argument about TOML being more complicated to edit while retaining comments and style. Yes, it’s a burden, but aren’t most of the tools which are going to implement this spec tools that already need to deal with pyproject.toml files? Ok, that’s not the case for pipx, but it doesn’t seek to edit the file IIUC. The existing tools I’d expect to implement this are things like Hatch and VSCode. They already have this need for full-fledged projects. The users and use case for single-file scripts aren’t the same as for full-blown projects, but the tools largely are, aren’t they? (And if they aren’t, isn’t it a long-term goal to make them so?)
Most importantly, I would like to comment on this:
By reserving metadata types starting with
X-, the specification allows experimentation with additional data before standardising.
and this:
While I am aware that “you should” statements can be frustrating from someone who is not [1] a meaningful contributor to packaging, I would like to say that, as a user of Python packaging, the last thing I want is more innovation and experimentation for tool UX. There are already way too many different tools for managing full-fledged packages and the resulting confusion is one of the main problems with packaging as it stands. Metadata for single-file scripts has comparatively prior art, so there is a unique chance to get it right from the start and not have lots of diverging tools and formats.
yet ↩︎