[FR] Move .config. (setup.cfg parser) into a separate package and vendorize it

[KOLANICH]

What's the problem this feature will solve?

Even though setup.cfg files are deprecated and their support gonna be removed somewhen, it is here to stay, there are enough packages using it. So there is a need to read these files. Unfortunately they cannot be read properly by generic configparser (at least without additional postprocessing). So an out-of-the-box solution is needed.

Describe the solution you'd like

The library parsing setup.cfg is splitted into a separate package, that can be used by tools that have to deal with setup.cfg even after setuptools drops support of this metadata format.

setuptools eliminates the built-in submodule and instead vendorizes that package.

Alternative Solutions

Not to drop support of setup.cfg.

Additional context

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

[abravalheri]

Thank you very much @KOLANICH for starting this discussion.

A different alternative was also previously proposed in #1688 (comment): to create a tool that translates setup.cfg into pyproject.toml.

This other issue is also relevant for this discussion: #3214.

[KOLANICH]

A different alternative was also previously proposed in #1688 (comment): to create a tool that translates setup.cfg into pyproject.toml.

Yeah, I know about your tool (and I have contributed into it). But your tool still has to parse setup.cfg, so it also needs the library for doing it.

[abravalheri]

I have absolutely no problem if setuptools decides to not use ini2toml (the tool is already fulfilling its purpose if it helps people to migrate).

I think that having an independent setup.cfg-parser is also a great approach. I just wanted to add the topic to the discussion (to complete the alternatives description).

In my mind the differences are the following:

• separated parsing package: simpler

• "transpiler" tool: guarantees that setuptools has only one way of ingesting configs (in a philosophical level, I think this is an advantage).

---

But your tool still has to parse setup.cfg, so it also needs the library for doing it.

One comment: ini2toml does not use the same parsing mechanics as setuptools.config. Instead it tries to do some sort of AST translation (with AST taken in the very loose sense), that would not be possible if setuptools.config was used in its entire glory (maybe some smaller parts could be reused).

---

Since I don't have a strong opinion in this topic (nor I think that we have an urgency on the topic), I will just join this conversation more as an observer.