tox-dev / toml-fmt

Format Python TOML configurations.
MIT License
3 stars 1 forks source link

Tables ordering issues #3

Open funkyfuture opened 4 weeks ago

funkyfuture commented 4 weeks ago

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]