Make it explicit that functions to parse `pyproject.toml` are not part of the API

[abravalheri]

setuptools does not explicitly list which functions are part of the exposed API and therefore users tend to consider everything public.

As pointed out in #3231, some users might try to reach out for a function to parse the TOML file.

Since pyproject.toml uses a data format that maps directly to Python builtin types (dicts, arrays, etc), it can be directly parsed by a TOML library, such as tomli or future tomllib.

Therefore my opinion is that we can explicitly sign that the modules used to parse pyproject.toml are internal by prefixing them with _.

[jnbolito]

Apologies for resurrecting this almost-a-year-old issue.
I just bumped into this issue now for a CI build pipeline I'm writing. FWIW, I don't think the pyproject.toml parsing function should be made private as it contains logic beyond simple toml parsing, especially when it comes to dynamic fields. Let's look at the following example and say I wanted to extract the version field:

[project]
name = "mypackage"
# (...)
dynamic = ["version"]

[tool.setuptools.dynamic]
version = { attr = "mypackage.__about__.__version__" }

Now I have two options: either reinvent the wheel and check if version is in dynamic or not and based on that do some hacky python path extensions and getattr's (essentially copying the parts from the private API that I need), or just use pyprojecttoml.read_configuration to do that heavy-lifting for me and get on with my life 😄. IMO, DevOps engineers and anyone writing non-trivial CI will probably carry on using the private API. Just my two cents. 🪙

[abravalheri]

@jnbolito, DevOps can use private APIs as long as they assume the risk associated with it.

There is also build.util.project_wheel_metadata that allow users to read core metadata from the project.