PROJ: linter/formatter rules for pyproject.toml

[paveldikov]

ruff currently primarily concerns itself with code content (most rules) as well as layout (INP comes to mind). It would be amazing if the scope were slightly expanded to also include project configuration, as that is so pivotal to a modern Python development environment.

Defective project configuration carries much the same implications as defective code, and is validatable in much the same way... hence proposing PROJ -- a rule set for pyproject.toml concerns.

Things like:

• bare minimum: ensure core pyproject.toml schema is valid
• forbid deprecated practices
  • e.g. implicit default setuptools build backend
• dependency lists should be alphabetically-sorted, line-delimited and each entry has a trailing comma (maybe with some idiomatic handling for special cases e.g. people grouping dependencies in thematic blocks using comments)

And whatever else comes to mind :-)

[MichaReiser]

See #10738

[paveldikov]

This is necessary, but I am proposing a more ambitious scope here.

#10738 would take care of the formatting concern quite nicely, but there is still schema- and convention- dependent linting that is an even bigger value add, I think.

[MichaReiser]

I see. Yeah, that makes sense. It's a bit hard to find but this has been proposed before: #10227 and #10487

[paveldikov]

Still different :-)

#10227 does not describe a specific usage of $markup_format (unless it's made schema aware, it is probably equivalent to a formatter rather than linter?)
#10487 has a different/narrower scope of ruff.toml & [tool.ruff] section. (There is some overlap, but I actually consider that of secondary importance to the core pyproject.toml spec)

I have my sights set on pyproject.toml particularly because I want ruff to be able to steer people away from sub-par project practices.

[paveldikov]

A good example of a desirable PROJ rule has just cropped up -- one that extends beyond simple TOML beautification & schema validation.

Entrypoints ([project.scripts] and [project.gui-scripts]) should point to modules:names that are actually importable (and, preferably, importable in isolated mode i.e. without reliance on cwd being on sys.path)

[terror]

I've been working on a tool that may fit this use case, check it out :) https://github.com/terror/pyproject. It's still early and a bunch of the rules are still being fleshed out.