I agree with several of the points recently made, that this is not packaging, that it only standardizes an existing practice, etc.
But the note that this may be perceived – whether or not it’s technically correct – as “packaging” or “part of the packaging ecosystem” resonates with me particularly strongly.
Most python users are probably hazy about the boundary between “packaging” and “workflow tools” and so forth. For them, these are all just “packaging tools for python”.
This line of reasoning leads me to slightly favor PEP 722 over 723 if we must choose one.
My rationale is that by staying intentionally distant from
pyproject.toml data, we better help users analogize the feature and its usage with
requirements.txt files, which is more accurate than analogizing it with building a package with dependencies.
I’m very concerned that voices calling for “no new ways of doing things” effectively leads to stalled progress.
Rather than standardizing on a new behavior which enhances, replaces, and improves upon past art – like requirements.txt files – we’ll be stuck with only the current standards and no new tooling.
As for use of special comments vs any other mechanism…
There are mechanical problems with basically any other solution. This ground has been trod pretty thoroughly here and in the PEP 723 thread, but I’ll try to summarize.
- it needs to be possible to parse the data in any language, not just python, so it can’t just be some runtime value or attribute
- if the value is visible at runtime, the runtime value might not match the verbatim values seen in a file, leading to a misleading discrepancy between runtime information and the spec
- shebangs, encoding comments, and other languages’ solutions to similar problems (e.g. embedded cargo.toml proposed for Rust) are a precedent for magic comments
- multiline strings introduce additional questions and confusion for users, f-strings would not work and escaping rules become more complex