Use inline arrays and tables

[adamchainz]

Follwo the setuptools docs by outputting inline tables for authors, license, etc.

For example:

[project]
name = "apig_wsgi"
version = "2.18.0"
license = {text = "MIT"}
authors = [{name = "Adam Johnson", email = "me@adamj.eu"}]
...

I found this tidier.

Also, I needed this fix because pyproject-fmt has a bug reordering non-inline tables: tox-dev/pyproject-fmt#110 . Comment there worth noting: tox-dev/pyproject-fmt#110 (comment) .

[adamchainz]

The tests pass because they compare on TOML semantics. I can update them if desired.

[diazona]

@sjlongland I remember you were interested in formatting of the output. What do you think?

FWIW in most cases it's intentional that the tests compare the parsed representation rather than the raw TOML-formatted output. Our main goal here is to produce a pyproject.toml file that is valid and results in the correct core metadata being generated for the final package. Getting the formatting to look nice is a good secondary goal, and I would be happy to add some dedicated tests that check that, but I'd still like to keep most of the tests focused on the primary goal of the content rather than the formatting.

[sjlongland]

@sjlongland I remember you were interested in formatting of the output. What do you think?

Definitely worth trying to maintain consistency in formatting… and for much of the setuptools documentation, they use inline tables.

I recall trying to make tomlkit emit that but not being familiar with its API, I struggled to bend it to my will, so if you've managed to do just that, fantastic.

FWIW in most cases it's intentional that the tests compare the parsed representation rather than the raw TOML-formatted output. Our main goal here is to produce a pyproject.toml file that is valid and results in the correct core metadata being generated for the final package. Getting the formatting to look nice is a good secondary goal, and I would be happy to add some dedicated tests that check that, but I'd still like to keep most of the tests focused on the primary goal of the content rather than the formatting.

Maybe an easy way to achieve that might be to use the usual semantic checks, but then pass a regex filter over the generated string to see that it matches an expected pattern for an inline table. That's assuming of course that tomlkit doesn't provide some sort of DOM-representation of the TOML document that we could analyse.

The important thing is that the data representation must be exactly that as expected… how it's formatted is really for us meat-bags: the computer doesn't care. So it's not a show-stopper not having tests that check the formatting is as-expected. Definitely a nice-to-have though to verify that it not only semantically matches, but also matches the expected visual format.