Well, if we want equal competition, then (as @steve.dower said) distutils should be moved out of the stdlib - on the one hand so it doesnât have an unfair âcomes with Pythonâ advantage, and on the other hand, so that it isnât unfairly limited by Pythonâs development cycles.
Given that setuptools is essentially a version of distutils with many enhancements that users have wanted over the years and distutils never provided, I fear that youâre going to end up either reimplementing a lot of setuptools, or looking very underpowered in comparison with setuptools. But itâs your choice, I guessâŚ
For a start that will mean implementing an equivalent of bdist_wheel for distutils. At the moment, distutils canât build wheels at all, which is why everyone uses setuptoolsâŚ
But if you want to enable people to use distutils without setuptools, then yes, a PEP 517 interface is essential. Weâre (slowly) removing all the ways in which the packaging ecosystem special-cases setuptools, in favour of standardised interfaces like PEP 517. Weâre not there yet, so there are still some areas where setuptools has preferential treatment (editable installs, for example) but the goal is 100% to make any build back-end that implements the standards an âequal citizenâ.
One other thing you should probably look at is manylinux support - I donât know to what extent code changes were needed in setuptools to handle manylinux, but Iâm pretty certain that any which were wonât have been backported to distutils.