-
Notifications
You must be signed in to change notification settings - Fork 12
Open
Labels
bugSomething isn't workingSomething isn't workinghelp wantedExtra attention is neededExtra attention is needed
Description
when i pass a file with these tables into pyproject-fmt (2.2.4):
[tool.flake8]
[tool.cff-from-621]
[tool.cff-from-621.static]
[tool.coverage.run]
[tool.coverage.report]
[tool.hatch.envs.linting]
[tool.hatch.envs.linting.scripts]
[tool.hatch.envs.unit-tests]
[tool.hatch.envs.unit-tests.scripts]
[tool.hatch.envs.mypy]
[tool.hatch.envs.mypy.scripts]these get reordered to:
[tool.hatch.envs.linting]
[tool.hatch.envs.linting.scripts]
[tool.hatch.envs.unit-tests]
[tool.hatch.envs.unit-tests.scripts]
[tool.hatch.envs.mypy]
[tool.hatch.envs.mypy.scripts]
[tool.flake8]
[tool.coverage.run]
[tool.coverage.report]
[tool.cff-from-621]
[tool.cff-from-621.static]it seems that the tables get sorted in reverse alphabetical order on their second level and further levels aren't considered for sorting at all.
in the somewhat similar tox-dev/pyproject-fmt#241 a certain "philosophy" is mentioned and the docs describe its aim as "consistency, predictability", nothing more specific to the ordering of tables. however neither would i consider reverse sorting as a commonly predicted result, nor is the different ordering depending on the table-level consistent. if those behaviours are intended, they should be spelled out in the docs.
as reference, this would be an outcome that i would consider consistent:
[tool.cff-from-621]
[tool.cff-from-621.static]
[tool.coverage.run]
[tool.coverage.report]
[tool.flake8]
[tool.hatch.envs.linting]
[tool.hatch.envs.linting.scripts]
[tool.hatch.envs.mypy]
[tool.hatch.envs.mypy.scripts]
[tool.hatch.envs.unit-tests]
[tool.hatch.envs.unit-tests.scripts]Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workinghelp wantedExtra attention is neededExtra attention is needed