Eventually deprecate `setup.cfg` with automatic conversion to `pyproject.toml`

[abravalheri]

This is a follow up of #1688.

As discussed in the linked issue, the approach setuptools would like to take is to eventually use a single declarative format (pyproject.toml) instead of maintaining 2 (pyproject.toml/setup.cfg).

Originally posted by Paul Ganssle in #1688 (comment):

Add pyproject.toml as the one true way to do declarative builds, moving all setuptools configuration over there and deprecating setup.cfg (partially what is discussed in #1160, and if we decide on that option we can move over to that issue).

Originally posted by Jason R. Coombs in #1688 (comment)

One way to ease the transition could be for the setup.cfg code to generate a .toml file and consume then have the pyproject.toml consumer just load both files. That way, a project seeking to transition would only need to do one build, manually merge the two .toml files, and delete setup.cfg.

Originally posted by Paul Ganssle in #1688 (comment)

I don't think we should warn if people use setup.cfg even when pyproject.toml is available, we should wait for pyproject.toml configuration to be stable for at least a year before actively pushing it like that.

Relevant tool: ini2toml

[thehappycheese]

Thankyou for posting this issue. As someone tinkering on the bleeding edge of packaging tools I have been so confused by the various PEPs and documentation. I thought pyproject.toml was the future but could not find anything definitive to suggest setuptools were going to deprecate setup.cfg.

[abravalheri]

Hi @thehappycheese please feel free to open a discussion if you still
have doubts, either here or in https://discuss.python.org/c/packaging/14. We will try our best to help.

But meanwhile we are in no rush to deprecated setup.cfg and pyproject.toml just landed (still being evaluated).

[thehappycheese]

Thanks @abravalheri I will take a look at the forums. Yes I understand setuptools has a big community to bring along for the journey when it happens :) I think it will be a great move though if it works out

[bskinn]

@abravalheri Is that milestone correctly named (setup.py deprecation)? I still use setup.py to provide specific dynamic content to build, and I would like to be able to keep that workflow.

I suppose -- if setup.py is to be deprecated eventually, in addition to setup.cfg, are there plans to develop a replacement mechanism for providing dynamic content within a setuptools build chain?

Thanks!

[abravalheri]

Sorry, @bskinn, the correct name should be setup.cfg. I will fix it.