Speaking on behalf of Ruff, I think we can support any of the proposals described here and would plan to do so were the PEP to be accepted.
Tools serving purposes unrelated to packaging (such as linters or code formatters, but not build frontends) which accept both single files and directories, and which can be configured though the
[tool.toolname]table of a
pyproject.tomlfile when invoked on a directory, SHOULD also be configurable via
__pyproject__of a single file.
I honestly want this because it’s much easier to implement and will have less of an impact on performance (since we only need to check for
__pyproject__ in very limited contexts), though I do think it sounds like a confusing user experience. (For example, not only would
ruff . and
ruff /path/to/file.py produce different results, but so would
ruff . vs. pre-commit IIUC, since pre-commit passes individual files.). We can support either setup though.
The TOML document MUST NOT contain multi-line double-quoted strings, as that would conflict with the Python string containing the document. Single-quoted multi-line TOML strings may be used instead.
Broadly, from an implementation perspective, the stricter the spec, the better… For example, it would be nice to know that it has to triple-quoted (as in the PEP), but also, can’t contain an implicit concatenation (if we’re encouraged to use a regex), that there can’t be multiple
__pyproject__ assignments (for correctness and removal of any ambiguity), etc. Again, purely from an implementation perspective, it’d be nice if it had to appear in the first N lines of the file, like the encoding pragma… but, that’s probably not a desirable user experience.
(Relatedly, how does this interact with
__future__ imports? I’d assume you want this to be at the top of the file, before imports, by convention (as in the PEP examples), but you can’t have assignments before
Anyway, we ship with a full Python parser, so it’s actually not super important to me whether we’re required to parse the AST or not in order to extract the TOML string. It would be nice if we could do it with a regex, but again, not strictly required for us. (Either way, we’d likely do a fast plaintext search to see if
__pyproject__ appears in the source, then do a slower search to actually extract it.)
P.S. Apologies if I’ve missed any of the nuance in the discussion, there was a lot to read through.