Here’s a status update on distutils2.
Vinay did the bulk of the work in his initial commit; we just had to re-add some mistakenly deleted helpers in d2.tests and d2.tests.support, change sysconfig imports and remove duplicate files (sysconfig.*).
A contributor did a huge commit to restore 2.4 compatibility. I pulled it, because it was a useful contribution, and am now in the middle of cleaning it: some conversions were not idiomatic or even buggy, just like when we converted from 2.x to 3.x.
Alexis and I have been working in parallel, with some unfortunate duplication. We’ve resolved to use the tracker or email to coordinate. When I am finished cleaning up the 2.4 compat changes, I’ll backport all outstanding changesets that were done in packaging, and then I’ll try to fix the few (on linux3^Wlinux) test failures.
When the d2 codebase matches packaging's again, it will be easy to keep both codebases in sync. I will edit the wiki page about contributing to state that I will accept patches made against d2 instead of packaging, to lower the contribution bar. It would be very useful to have buildbots.
A question: What about distutils2 for Python 3.x? I think we could keep the stdlib codebase compatible with 3.1 and use a semi-automated process to extract cpython3.3/Lib/packaging to distutils2-py3/distutils2 and rename imports. (IIRC PyPI will require us to play games to have both 2.x and 3.x versions of distutils2.)
Another question: What about the docs? Can we just point people to docs.python.org and tell them to mentally replace packaging with distutils2? If that is judged unacceptable, then I’ll synchronize the docs in the d2 repo, but that’s hours I won’t spend on bugs or features.